Messaging
While components call each other directly, everything is simple — a call either returns a result or fails. Queues and events begin where that simplicity is gone: a producer puts a message into the broker and moves on, not knowing who will read it or when, and a process crash can land between the DB write and the event publish. Here the interviewer checks not knowledge of a buzzword, but the ability to reason about consistency and delivery under asynchrony.
The central trap of this topic is carrying synchronous-call intuition into the broker. In a monolith a write and a publish are atomic because they are one call; split them across two systems and you get a dual-write, a partial failure, and only eventual consistency. The second trap is belief in "free" guarantees: that the broker provides exactly-once on its own, that a redelivery can be ignored, that a dead-letter queue is a bin for bad messages. Not so: duplicates are neutralized only by an idempotent consumer, and a DLQ is a buffer for inspection. This topic breaks messaging into layers — from how components communicate down to how exactly a message arrives effectively once.
Topic Map
- Event-driven architecture — components communicate through a broker with events instead of direct calls; what it buys and what it costs.
- Message broker — async decoupling of producer and consumer;
RabbitMQentities: exchange, queue, binding, and the contrast with theKafkalog. - Message delivery guarantees — at-most-once, at-least-once, and effectively-once, and why idempotency is mandatory under retries.
- Kafka consumer groups — one partition per consumer in a group, idle extras, rebalance, and the offset commit on failure.
- Message ordering in Kafka — order guaranteed only within a partition, and the partition key for related events.
- The outbox pattern — how one local transaction solves the dual-write problem, with a relay publishing events after commit.
- Dead-letter queue — a side queue for poison messages, inspected and replayed with idempotent consumers.
- Notification fan-out — an event to a durable broker and a fan-out of per-channel deliveries with independent retries and deduplication.
- A Postgres job queue —
SELECT ... FOR UPDATE SKIP LOCKED, a lease timeout, and dead-lettering for durable background jobs without a separate broker.
Common Mistakes and Traps
| Mistake | Consequence |
|---|---|
| Treating an event-driven system as strongly consistent | False expectations — it is only eventually consistent by nature |
| Thinking events are just logging | Missing that the event itself is the real communication channel |
| Thinking the producer must know the list of consumers | Decoupling is lost — you cannot add a consumer without editing the producer |
| Swapping at-least-once and at-most-once | at-least-once duplicates, at-most-once loses — not the reverse |
| Believing the broker gives end-to-end exactly-once for free | Duplicates reach the consumer without its own deduplication |
Sending ACK before processing the message | A crash mid-handler loses the message — the broker won't redeliver |
| Comparing offsets of messages from different partitions | There is no order across partitions — they are independent scales |
| Running more consumers than partitions | The extras sit idle — parallelism is bounded by the partition count |
| Thinking the outbox relay publishes inside the same transaction | Wrong model — the relay runs separately, after commit |
| Doing a dual-write — write to the DB then publish the event | A crash between the steps loses the event forever |
| Treating the DLQ as a way to "throw away" a bad message | A forgotten DLQ is silent data loss disguised as processing |
| Forgetting handler idempotency under at-least-once | A redelivery yields a second effect — a duplicated payment |
Interview Relevance
Queues and events are a mandatory topic at the senior level of a Go interview, and the question is not a whiteboard diagram but an understanding of delivery and consistency. The interviewer checks whether you blindly carry monolith intuition into a distributed system.
What interviewers usually check:
- What event-driven architecture pays for loose coupling — asynchrony, harder debugging, only eventual consistency.
- How
RabbitMQdiffers fromKafka— a smart broker with routing versus a partitioned log with the offset on the consumer side. - How at-least-once differs from at-most-once and why at-least-once is safe only with an idempotent handler.
- How
Kafkaguarantees order — only within a partition, and why a partition key is used for related events. - What the dual-write problem is and how the outbox pattern solves it with one local transaction plus a relay after commit.
- Why a dead-letter queue is needed and why it requires inspection, not a silent drop.
- How a fan-out on a durable broker gives independent per-channel retries and effectively-once via deduplication.
A typical wrong answer: "the broker guarantees exactly-once itself, the consumer has nothing to do." This triggers a discussion that end-to-end exactly-once in a distributed system is practically unreachable and is approximated as effectively-once — at-least-once plus deduplication by an idempotency key on the consumer side.