Architecture Tradeoff Explorer
Every comparison answers the same five questions — use when, avoid when, complexity, operational cost, failure modes — so the decision is about your constraints, not the fashion of the year.
Monolith vs MicroservicesREST vs GraphQLREST vs gRPCSynchronous call vs Asynchronous (queue)Relational (SQL) vs NoSQL (document / key-value)Queue (point-to-point) vs Pub/Sub (topic)Event-driven vs Request/responseCache (Redis / CDN / in-process) vs DatabaseCQRS vs CRUDEvent sourcing vs State storage
A queue delivers each message to one of the competing consumers; a topic delivers each message to every subscriber. Queues distribute work; topics broadcast facts. The choice is "how many parties must see this?"
| Queue (point-to-point) Message Queues | Pub/Sub (topic) Event-Driven Architecture | |
|---|---|---|
| Use when | One kind of work with one consumer group: send this email, resize this image, run this export. Competing consumers scale by adding workers. | A fact several independent consumers care about — OrderCreated to email, inventory, analytics, search — and adding a consumer must not change the producer. |
| Avoid when | A second consumer appears and you find yourself enqueuing the same message twice to two queues. | There is one consumer and there will be one consumer; the topic's subscription and offset management is machinery for nothing. |
| Complexity | Low: enqueue, dequeue, ack, visibility timeout, retry, dead-letter queue. | Medium: topics, subscriptions or consumer groups, offsets, partition keys for ordering, retention and replay, schema evolution across consumers. |
| Operational cost | Watch depth and oldest-message age; scale workers by depth. | Watch consumer lag per group; a slow subscriber does not block others but its lag grows; retention decides how far back a new consumer can replay. |
| Failure modes | A poison message retried forever; consumer throughput below producer rate; a message lost when acked before the work was done. | A consumer that is not idempotent replaying after a rebalance; ordering broken by a random partition key; the producer publishing after the commit without an outbox. |
| Data flow | Producer → queue → one of N workers → ack → message gone | Producer → topic → each subscriber group reads at its own offset; message retained |
| Consistency | Work done once (at-least-once + idempotency) | Every subscriber eventually sees every event; the truth is the producer's state, not the topic |
| Replay | None once acked | Rewind an offset to reprocess history (Kafka-style logs) |