Event-Driven Architecture vs. REST: A Practitioner's Decision Framework

The first mistake engineers make when evaluating event-driven architecture is treating it as an upgrade to REST. It is not. They solve different communication problems, and applying event-driven patterns to a domain where REST is sufficient creates operational complexity with no corresponding benefit.

The second mistake is the inverse: defaulting to REST for every inter-service interaction because it is familiar, and then engineering around its limitations with polling, retry storms, and synchronous fan-out chains that become reliability liabilities.

This post establishes the framework for making the choice correctly.

What REST is Excellent At

REST's synchronous, resource-oriented model is genuinely good for a specific class of problems:

CRUD operations with immediate consistency requirements. A user updates their profile and expects to see the updated data on the next page load. A synchronous PUT → 200 response with the updated resource is the correct model. Eventual consistency here creates a poor user experience.

Public APIs consumed by external clients. REST with OpenAPI is an industry-standard, well-tooled interface. External consumers understand it. CDN caching of GET responses is HTTP-native. Versioning strategies (URL versioning, Accept header versioning) are mature. Webhooks provide the push notification layer when needed.

Simple request-response interactions between a small number of services. If Service A calls Service B and needs the response before it can respond to its own caller, REST is the natural fit. The coupling is explicit and intentional.

Where REST breaks down is at the boundaries of these use cases:

• Fan-out: Service A needs to notify Services B, C, D, E after an action. Synchronous HTTP calls to each service means A's latency = sum of B+C+D+E latency. Any one downstream failure causes A to fail or requires A to implement bulkhead isolation for each dependency.
• Temporal coupling: The caller and callee must both be available simultaneously. If the email service is down, and you're calling it synchronously in your order flow, orders fail.
• Cascading failures: A slow downstream service holds connections, exhausts your thread pool or semaphore limit, and can take down the upstream service.
• Audit and replay: REST has no inherent log of what happened. Reconstructing system state after a bug requires re-querying every service.

What Event-Driven Architecture Solves

Events are facts — immutable records of something that happened. order.created, payment.charged, inventory.reserved are not commands (which can be rejected); they are facts (which have already occurred). This distinction is important.

Temporal decoupling. The producer publishes an event and returns immediately. It does not care whether the consumers are currently available. The message broker (Kafka, RabbitMQ, Redis Streams) durably stores the event until consumers are ready to process it. This eliminates the availability coupling between services.

Independent scaling. Each consumer service scales based on its own processing rate. If the email notification service falls behind, its consumer lag grows — but it does not affect order processing throughput. The scaling signal (consumer lag) is explicit and monitorable.

Replayability. Kafka retains events for a configurable retention period (or indefinitely with tiered storage). You can replay the entire event log to rebuild a read model, populate a new service that was added after the fact, or audit exactly what happened in a given time window.

Organic extensibility. Adding a new consumer (analytics, fraud detection, ML feature pipeline) requires no changes to the producer. The producer continues publishing events; the new consumer subscribes. In a REST model, adding a new downstream service requires modifying the producer to make a new HTTP call.

Failure Modes Specific to Event-Driven Systems

Idempotency is non-negotiable. Message brokers guarantee at-least-once delivery. Consumers will receive duplicate messages — during reprocessing after a consumer crash, during network partitions, or during Kafka broker leader elections. Every consumer must be idempotent: processing the same event twice must produce the same state as processing it once.

Implement idempotency with an event_id deduplication table:

1CREATE TABLE processed_events (
2    event_id    UUID PRIMARY KEY,
3    processed_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
4);

Before processing, check for existence. After successful processing, insert. Wrap both in the same database transaction as your business logic update.

Schema evolution is a first-class concern. In REST, breaking API changes are caught at the contract boundary. In event-driven systems, breaking changes to event schemas silently break consumers that may be in a different deployment lifecycle. Use a schema registry (Confluent Schema Registry with Avro, or JSON Schema with compatibility enforcement) and enforce backward-compatible evolution.

Distributed saga for multi-step transactions. An order flow that spans inventory reservation, payment charging, and fulfillment scheduling cannot use a database transaction across three services. The saga pattern manages this with compensating transactions: each step publishes a success event that triggers the next step, and each step also handles rollback events from downstream failures.

1order.created →
2  InventorySvc: reserves stock → inventory.reserved →
3    PaymentSvc: charges card → payment.charged →
4      FulfillmentSvc: schedules shipment
5
6  [on failure] payment.failed →
7    InventorySvc: releases reserved stock → inventory.released

The saga pattern requires careful design but provides the same end-to-end consistency guarantee as a distributed transaction with a fraction of the coupling cost.

Broker Selection: Kafka vs. RabbitMQ vs. Redis Streams

Apache Kafka is appropriate when: event retention and replay are requirements, event throughput exceeds tens of thousands per second per partition, you need consumer groups with independent offsets, or your use case includes event sourcing / CQRS with a reliable event log as the source of truth.

RabbitMQ is appropriate when: you need sophisticated routing (topic exchanges, headers exchanges), message TTL with dead-letter queues, or per-message acknowledgment semantics that guarantee exactly-once processing in a simpler operational model. It is easier to operate than Kafka for moderate-throughput use cases.

Redis Streams is appropriate when: you already operate Redis, throughput is moderate (under 100k events/second), and you do not need Kafka's log retention semantics. It provides consumer groups and acknowledgment semantics. It is the lowest operational overhead option.

The Hybrid Pattern That Actually Scales

At mature engineering organizations, the production pattern is not "REST or events" — it is:

Synchronous REST for user-facing, consistency-required, cacheable interactions.

Asynchronous events for all service-to-service side effects.

Event-carried state transfer for read models: instead of services calling each other's APIs to read data, services maintain their own denormalized read models updated by consuming events from the authoritative service.

This eliminates synchronous inter-service read traffic and the coupling it creates, while preserving synchronous consistency where users require it.

The decision framework: if the caller needs the result to continue, use REST. If the caller is triggering a side effect that does not block the response, use events. If you are building read models across service boundaries, use event-carried state transfer.