Message-Bus Architecture Deck
Forty concise cards on the principles, patterns, and operational realities of message buses. Click a question to test yourself—click again to reveal the answer.
1. What core problem does a message bus solve in a growing microservices system?
It removes tight, brittle point-to-point links by introducing an intermediary (the bus), enabling asynchronous, resilient, many-to-many communication.
2. Name the four primary logical parts of a message bus.
• Bus & channels (topics/queues)
• Message envelope
• Publishers (producers)
• Handlers (consumers/subscribers)
3. What metadata is typically found in a message envelope?
• Message type/name
• Unique ID
• Timestamp/origin
• Headers such as routing keys, correlation IDs, or schema version
4. How does a command bus differ from an event bus in delivery semantics?
Command bus delivers each command to exactly one handler (one-to-one); event bus fans out each event to zero, one, or many handlers (one-to-many).
5. Why is “no consumer” usually an error for commands but acceptable for events?
Commands expect the action to be performed; events simply announce facts and impose no obligation to react.
6. Define synchronous vs. asynchronous messaging in the context of a bus.
• Synchronous – sender blocks, waiting for handling/response via the bus.
• Asynchronous – sender publishes and continues; processing is decoupled in time.
7. What is the most common delivery guarantee used in robust systems and why?
At-least-once delivery—ensures messages aren’t lost, accepting that duplicates may occur and must be handled.
8. Explain idempotency and its role in message processing.
An operation is idempotent if reapplying it has no additional effect; it makes consumers safe against duplicate deliveries in at-least-once systems.
9. What purpose does a dead-letter queue (DLQ) serve?
It isolates messages that repeatedly fail processing, preventing them from blocking the main flow and allowing manual inspection or repair.
10. Give two strategies for preserving message ordering when it matters.
- Guarantee FIFO per channel/partition and use a single consumer group.
- Key related messages to the same partition or process sequentially in one consumer.
11. What is the Saga pattern?
A series of local transactions across services coordinated by messages, with compensating actions to maintain consistency without global ACID transactions.
12. Contrast saga choreography with saga orchestration.
• Choreography – each service reacts to events and emits the next event; no central brain.
• Orchestration – a dedicated coordinator sends commands and awaits results, centralising the workflow.
13. Why is the Transactional Outbox pattern used with sagas?
To atomically persist both the local DB change and the outbound message, eliminating the “commit-then-crash before publish” window.
14. What is schema coupling in an event-driven system?
The implicit dependency producers and consumers share on message structure and meaning, even though they’re decoupled in space and time.
15. List two safe, backward-compatible schema changes.
• Add a new optional field.
• Publish a new event version/channel while still emitting the old one during transition.
16. How can a schema registry aid message evolution?
It stores versions, enforces compatibility rules, and prevents producers from publishing breaking changes.
17. Why are correlation IDs critical for observability in async flows?
They let logs and tracing systems stitch together the causal chain of events across services and time.
18. Define back-pressure and one broker-level mechanism to enforce it.
Controlling producer rate when consumers lag; e.g., RabbitMQ can stop acknowledging new publishes until queue depth drops.
19. Give an application-level back-pressure strategy for non-critical data.
Drop or sample low-priority messages when lag or queue size exceeds a threshold.
20. What hidden coupling pitfall can arise from event ordering assumptions?
If Service B silently relies on Event X arriving before Event Y, a re-ordering bug can silently corrupt state.
21. How can the message bus itself become a single point of failure, and one mitigation?
All traffic flows through it; mitigate with clustered, highly-available broker deployments and fail-over configs.
22. Briefly describe a lightweight in-process bus use case.
In a modular monolith, components publish domain events inside the same process (e.g., .NET MediatR) for clean layering without external infrastructure.
23. What distinguishes a log-based bus like Kafka from a simple queue?
• Durable, replayable, append-only topics
• Consumer-controlled offsets
• High throughput
• Multiple independent consumer groups
24. Mention one advantage and one disadvantage of an Enterprise Service Bus (ESB).
• Advantage: rich routing, transformation, orchestration in one place.
• Disadvantage: central complexity and potential performance bottleneck.
25. When might exactly-once semantics be worth the extra complexity?
Financial or inventory operations where duplicate effects are unacceptable and cannot be made idempotent downstream.
26. What is exponential backoff in retry logic?
Increasing the wait time between successive retries to reduce load on a failing service.
27. Name two metrics that indicate consumer lag or bottleneck on a bus.
• Queue/topic length
• Consumer-group offset lag (messages behind)
28. Why should large binary payloads generally not be sent through the bus?
They bloat broker storage, increase network overhead, and slow consumers; better to send a reference (URL or object ID).
29. Give an example of a fire-and-forget use case ideal for an event bus.
Publishing a “UserRegistered” event that triggers welcome-email and analytics services independently.
30. How does a request-reply pattern use a message bus synchronously?
Sender publishes a request message and blocks, waiting for a correlated response message before continuing.
31. What business rule signals an architecture might need to switch from direct APIs to a bus?
When cascading failures or slowdowns in one service frequently propagate to others, causing widespread outages.
32. In terms of coupling, which is looser: event bus or command bus, and why?
Event bus—publishers don’t assume any listener exists; commands assume one handler must exist to fulfil intent.
33. Explain the term fan-out delivery.
The broker copies a published event to every subscribed consumer, enabling one-to-many communication.
34. What does temporal decoupling mean?
Producers and consumers don’t need to be online at the same time; the bus buffers messages until consumption.
35. Why are compensating actions required in sagas?
Because each local transaction may succeed independently; a later failure must be undone to maintain overall consistency.
36. What is the primary trade-off when enforcing global message ordering?
Lower throughput and parallelism, because messages must be processed sequentially or pinned to a single consumer.
37. State the “dumb pipe, smart endpoints” principle in event-driven systems.
Keep the bus simple—just transport messages—and push business logic into services, avoiding ESB-style over-centralisation.
38. How can consumer-driven contracts reduce integration breakage?
Consumers publish their expected schemas; producers run tests to ensure any change still meets those expectations.
39. What operational tool alerts engineers to poisoned messages stuck in DLQs?
Monitoring DLQ size and alerting when the message count exceeds a threshold.
40. Summarise the key advantage of adopting a message bus early in scaling microservices.
It establishes a uniform, resilient communication backbone, preventing ad-hoc sprawl and easing future growth, observability, and fault tolerance.