What this prompt does
This prompt asks the AI to design an event-driven system with Spring Boot and Apache Kafka for [domain], focused on the reliability details that decide whether events are lost. For your [events] it produces Avro or JSON schema definitions registered in [schema_registry], a producer using the transactional outbox pattern, a consumer with [consumer_group] configuration, dead-letter handling with [max_retries] retries, exactly-once semantics config, a backward/forward-compatible versioning strategy, Spring Cloud Stream bindings, EmbeddedKafka integration tests, consumer-lag monitoring, and a Kafka Connect sink projecting to [sink_target] — with docker-compose for Kafka, Zookeeper, and the schema registry.
The structure works because Kafka systems quietly lose data when the outbox, retries, and dead-letter paths are not designed deliberately. Locking in reliable publishing, exactly-once semantics, and consumer-lag monitoring before writing the first producer prevents the failure modes that are hardest to debug after the fact. The schema-registry and versioning steps matter just as much, since an event format that changes without a compatibility plan can break every downstream consumer at once, long after the producer change shipped.
When to use it
- You are building a Kafka-based pipeline for
[domain]and need reliable publishing, not fire-and-forget. - You want the transactional outbox pattern so events and database changes commit atomically.
- You need dead-letter handling and retries so a poisoned event does not block a partition.
- You want a schema registry and a compatibility strategy so event evolution stays safe.
- You need consumer-lag monitoring to catch consumers falling behind before it becomes an incident.
- You want a projection of events into
[sink_target]for search or read models.
Example output
Expect schema files for each event registered with [schema_registry], a producer service implementing the outbox pattern, a consumer with group and retry config, dead-letter topic handling, exactly-once configuration, Spring Cloud Stream bindings, EmbeddedKafka tests, lag-monitoring setup, a Kafka Connect sink config for [sink_target], and a docker-compose file for the full stack. It is delivered as an interconnected producer/consumer system rather than a single class.
Pro tips
- Name your real
[events]so schemas and topic structure reflect your domain rather than placeholders. - Choose
[schema_registry]and format (Avro vs JSON) deliberately, since compatibility checking behaves differently between them. - Keep
[max_retries]modest and pair it with the dead-letter topic; endless retries on a poison message stall the partition. - Set
[consumer_group]strategy to match how you scale consumers, as partition assignment depends on it. - Treat the outbox pattern as essential when events must stay consistent with database writes — do not skip it for convenience.
- Iterate by asking how a specific schema change stays backward-compatible, or how a failed event flows to the dead-letter topic and back.
