What this prompt does
This prompt asks the AI to design an event-driven microservices architecture for a [domain] platform built from [services]. It covers ten areas: an event bus on [message_broker], versioned event schemas with Avro or Protobuf, [consistency_pattern] for cross-service consistency, CQRS for [read_heavy_service], the saga pattern for [distributed_transaction], an event store with replay, service discovery and gateway, circuit breakers and bulkheads, distributed tracing with [tracing_tool], and data ownership via bounded contexts.
The structure works because moving from a monolith to events means trading simple transactions for eventual consistency, which is where most designs go wrong. Naming the [services] forces explicit bounded contexts and data ownership. [message_broker] shapes the event-bus and replay capabilities, [consistency_pattern] decides how cross-service writes reconcile, and [distributed_transaction] gives the saga a concrete flow — like reserving inventory, charging payment, then confirming an order — so the compensating-transaction logic is real rather than abstract.
When to use it
- You're decomposing a monolith and need bounded contexts and data ownership defined
- You're adopting
[message_broker]and want event schema versioning done right - You need a saga design for a real
[distributed_transaction]with compensation - You're applying CQRS to a
[read_heavy_service]and want the read/write split justified - You need distributed tracing with
[tracing_tool]across services - You want circuit breaker and bulkhead patterns specified, not assumed
Example output
Expect an architecture doc: a service map with bounded contexts, an event-bus design on [message_broker], versioned event schema examples, a CQRS layout for [read_heavy_service], a saga sequence for [distributed_transaction] with compensating steps, an event-store and replay design, and failure scenarios with rollback strategies. It usually includes an event-flow diagram and calls out where eventual consistency bites.
Pro tips
- List
[services]precisely; vague service names produce blurry bounded contexts and leaky data ownership - Make
[distributed_transaction]a concrete multi-step flow so the saga's compensating transactions are real and testable - Pin
[consistency_pattern]deliberately — eventual consistency with compensation is flexible but demands idempotent handlers - Choose
[message_broker]based on your needs; Kafka's log-replay strengths differ from a traditional queue's - Ask the model to expand the failure scenarios; happy-path event flows hide the hard parts
- Insist on idempotency in every event handler — at-least-once delivery means duplicates will happen
