What this prompt does
This prompt designs a microservices communication layer using MassTransit in [dotnet_version] with [message_broker]. It defines [contract_count] message types — commands, events, and request/response — in a shared contracts library with versioning, builds consumers for [consumer_scenarios] with a [retry_strategy] and dead-lettering, implements a saga state machine for [saga_scenario], configures the transactional outbox with [outbox_storage], sets up exchange and queue topology for [topology_requirements], and integrates distributed tracing via [telemetry_tool].
The structure works because a system that outgrows direct service calls needs messaging that fails cleanly rather than corrupting state. The saga defines states, transitions, and compensating actions so a failed step rolls back instead of leaving an order half-processed, and the outbox pattern guarantees delivery even when the broker is briefly unavailable. The MassTransit test harness and [telemetry_tool] tracing are what keep distributed flows debuggable when something goes wrong across service boundaries.
When to use it
- A system has outgrown direct service calls and needs reliable, decoupled messaging
- You are defining
[contract_count]message contracts and need a versioning strategy in a shared library - You need consumers for
[consumer_scenarios]with a clear[retry_strategy]and dead-letter handling - A multi-step process like
[saga_scenario]needs a saga with compensating actions on failure - You want the transactional outbox with
[outbox_storage]so messages aren't lost if the broker is down - You need distributed tracing across service boundaries via
[telemetry_tool]
Example output
Expect a design with code: a shared contracts library defining commands, events, and request/response messages with versioning, consumers with retry and dead-letter configuration, a saga state machine with states, transitions, and compensating actions, transactional-outbox setup, exchange and queue topology with naming conventions and bindings, test-harness examples for consumers and sagas, distributed-tracing integration, and containerized deployment configuration with health checks and graceful shutdown.
Pro tips
- Version your
[contract_count]message contracts from the start, since changing a published message shape later without versioning breaks every consumer that depends on it - Tune
[retry_strategy]to distinguish transient from permanent failures — immediate retries then exponential backoff handles blips, but a poison message should reach the error queue, not retry forever - Design saga compensating actions for
[saga_scenario]deliberately; a failed payment must release reserved inventory, or you leak state that's painful to reconcile - Enable the transactional outbox with
[outbox_storage]so a message and its database change commit together, avoiding the lost-message gap if the broker is briefly down - Use the MassTransit test harness to assert message flow without a live broker, which keeps saga and consumer tests fast and deterministic
- Add
[telemetry_tool]tracing early, because correlating a request across several services after the fact is far harder than instrumenting it up front
