11. Distributed Systems Patterns

Favor idempotency and eventual consistency patterns to achieve reliability under failure.

Question: How do you achieve "exactly-once" processing in a distributed system?

Answer: True "exactly-once" is nearly impossible to guarantee. The standard pattern is to build an "at-least-once" delivery system and then enforce idempotency on the consumer side to achieve an "effectively-once" outcome.

Explanation: Idempotency means that performing the same operation multiple times has the same effect as performing it once. This can be implemented by having the producer generate a unique idempotency key for each message. The consumer then tracks the keys of processed messages and discards any duplicates it sees.

Question: What is the Transactional Outbox pattern?

Answer: The Transactional Outbox pattern is a way to reliably publish events in response to a database change. Instead of writing to a business table and then making a separate call to a message broker (which can fail), you write both the business state and the event to be published into an "outbox" table within the same local database transaction. A separate process then reads from this outbox table and reliably publishes the events to the message broker.

Question: What is the Saga pattern and when to use it?

Answer: Saga coordinates a long-lived transaction across services using a sequence of local transactions with compensating actions on failure.

Explanation: Implement via choreography (events) or orchestration (central coordinator). Choose based on coupling and visibility needs.

Question: What is a circuit breaker and why use it?

Answer: A circuit breaker stops calls to an unhealthy dependency after repeated failures, allowing it to recover and protecting your system.

Explanation: States: closed -> open -> half-open. Use timeouts and failure thresholds.