Skip to content
System Design

Messaging and Streaming

Scope

Asynchronous communication systems that enable decoupling and scaling, including message queues, task queues, and publish/subscribe (pub/sub) systems.

Why This Topic Exists

Messaging systems are the backbone of scalable, decoupled architectures. They allow different parts of a system to communicate without being directly connected or available at the same time, improving resilience, scalability, and responsiveness.

Core Tradeoffs

  • Delivery Guarantees: The complexities of “at-least-once,” “at-most-once,” and “exactly-once” delivery, and the engineering effort required for each.
  • Durability vs. Performance: The choice between in-memory brokers (e.g., Redis) for high speed and disk-based brokers (e.g., RabbitMQ, SQS) for higher durability and message persistence.
  • Ordering: The difficulty of maintaining strict message order, especially in a distributed, partitioned system.
  • Pull vs. Push Consumers: Whether consumers poll for messages or have messages pushed to them, which impacts load distribution and complexity.

Common Failure Modes

  • Duplicate Message Processing: A consumer processes a message but fails before acknowledging it, leading to another consumer processing the same message. This can cause data corruption if the operation is not idempotent.
  • Poison Pill Messages: A malformed or unprocessable message that repeatedly causes consumers to crash, potentially blocking a queue.
  • Back Pressure Collapse: Producers overwhelm the message broker or consumers, leading to ever-increasing queue lengths, high latency, and eventual system failure.
  • Consumer Lag: In pub/sub or streaming systems, a slow consumer can fall far behind the head of the stream, leading to stale data or running out of retention space.

Interview Signals

A senior candidate moves beyond simply naming tools (“use Kafka”) and discusses the nuances of idempotency, delivery guarantees, and failure recovery. They should be able to explain the “poison pill” problem and strategies for handling back pressure.

  • Idempotency
  • Communication
  • Scalability
  • Reliability
  • Backpressure