What is the difference between event-driven architecture and message queuing?

Message queuing (SQS, RabbitMQ) is one implementation mechanism for event-driven architecture, where messages are consumed by one consumer and removed from the queue. Event streaming (Kafka, Kinesis) publishes events to a log that multiple independent consumer groups can read at their own pace. Event-driven architecture is the broader pattern; message queuing and event streaming are the underlying transport technologies with different delivery semantics.

How do I handle the need for an immediate response in an event-driven system?

The request-reply pattern over messaging achieves synchronous semantics on top of async infrastructure. The caller sends a message with a reply-to queue address and a correlation ID, then polls or blocks on that queue waiting for a response. AWS Step Functions, Temporal, and similar workflow engines provide higher-level abstractions for this pattern. For user-facing operations, it is often simpler to use synchronous HTTP for the initial response and event-driven processing for downstream work triggered by that call.

What is the saga pattern and when do I need it?

The saga pattern manages data consistency across multiple services in an event-driven workflow. Rather than a distributed transaction (which requires 2-phase commit across services), a saga decomposes an operation into a sequence of local transactions, each publishing an event that triggers the next step. If a step fails, compensating transactions undo the preceding steps. Sagas are essential for multi-service business processes (order fulfillment, user onboarding) where partial failures must be handled gracefully without global locks.

System Architecture

Event-Driven vs Request-Response Architecture

Event-driven and request-response are foundational communication patterns that shape how services interact across your system. The right choice depends on whether your operations are inherently synchronous (a user expecting an immediate result) or asynchronous (background work that can proceed independently of the caller), and how tightly your services should be coupled.

Halkwinds Verdict—Request-response is the natural pattern for synchronous, user-facing interactions where the caller needs an immediate result — REST APIs, GraphQL queries, and RPC calls. Event-driven architecture enables loose coupling, resilience, and high-throughput asynchronous processing, making it the preferred pattern for workflows, integrations, real-time data pipelines, and any operation where the producer should not wait for downstream completion.

Option A

Event-Driven

Asynchronous, decoupled communication through events and message brokers

Typical Cost

Managed brokers: AWS SQS ($0.40 per million messages), AWS EventBridge ($1 per million events), AWS MSK (Kafka) from $0.21/hour per broker. Kafka on Kubernetes requires platform engineering investment.

Timeline

Basic producer/consumer with SQS or EventBridge: 1–3 days. Full event-driven workflow with saga orchestration, dead-letter queues, and distributed tracing: 3–8 weeks.

Pros

Temporal decoupling — producers and consumers operate independently; the producer does not wait for downstream processing to complete

High resilience — events are persisted in the broker (Kafka, SQS, EventBridge), so consumers can fail and recover without data loss

Natural horizontal scaling of consumers independent of producers

Enables complex workflows and sagas across multiple services without tight point-to-point coupling

Supports multiple independent consumers processing the same event for different purposes (fan-out, audit, analytics)

Cons

Debugging and tracing are harder — distributed correlation IDs and event replay are required to understand system behavior

No immediate feedback to the original caller; implementing request-reply patterns over async messaging adds complexity

Eventual consistency — downstream state may lag behind the originating event, requiring careful design for time-sensitive reads

Broker infrastructure (Kafka, RabbitMQ, AWS MSK) adds operational complexity, cost, and an additional failure domain

Error handling and compensating transactions (saga pattern) for failed events require explicit design effort

Option B

Request-Response

Synchronous, direct communication where callers receive immediate results

Typical Cost

Minimal additional infrastructure cost beyond the services themselves. API Gateways (AWS API Gateway, Kong) add $3.50 per million API calls on AWS. REST/gRPC services run on existing container or serverless infrastructure.

Timeline

REST API with OpenAPI spec: 1–5 days per service. gRPC service with client/server code generation: 2–7 days. Full API gateway integration with auth, rate limiting, and monitoring: 1–3 weeks.

Pros

Simple, intuitive programming model — call a service, get a result; no async machinery required

Immediate feedback enables rich user experiences where the UI updates directly from the API response

Strong consistency — the caller receives the state of the system at the time of the call

Extensive tooling for REST (OpenAPI, Postman, Swagger) and gRPC makes design, testing, and documentation straightforward

Easier to debug — a single request-response trace captures the entire interaction in a single log stream

Cons

Temporal coupling — if the downstream service is unavailable or slow, the caller blocks and may time out

Cascading failures are more likely — a slow dependency propagates latency up the call chain to the end user

Harder to scale independently — adding consumers requires routing changes or load balancer reconfiguration

Not well-suited for fan-out operations; notifying 10 downstream services synchronously creates a serial bottleneck

Long-running operations (minutes or longer) are awkward to model in synchronous HTTP without polling or webhook callbacks

Side-by-Side

Detailed Comparison

Dimension	Event-Driven	Request-Response	Winner
Coupling	Loose — producers and consumers are independent; changes to one do not require changes to the other	Tight — caller and callee must agree on API contract; version changes require coordination	Event-Driven
Consistency Model	Eventual — consumers may process events with a lag; state reflects past events, not the present moment	Strong — caller receives the current state of the system at call time	Request-Response
Resilience to Failures	High — events persist in the broker; consumers recover after failure without data loss	Lower — caller blocks on downstream availability; cascading failures propagate synchronously	Event-Driven
Debugging & Observability	Complex — requires distributed tracing (OpenTelemetry, Jaeger) and correlation IDs across async boundaries	Straightforward — single request trace captures the full interaction	Request-Response
Latency for End User	Not applicable to synchronous user interactions; adds processing delay for background workflows	Immediate response — optimal for user-facing operations requiring sub-second feedback	Request-Response
Throughput & Scalability	Consumers scale independently; brokers absorb bursts without back-pressure on producers	Caller blocks until response; scaling requires adding instances behind a load balancer	Event-Driven
Fan-Out	Natural — one event can be consumed by many independent subscribers simultaneously	Awkward — sequential synchronous calls to multiple services create serial latency	Event-Driven
Error Handling	Dead-letter queues, retry policies, and compensating transactions handle failures asynchronously	Immediate error response allows caller to handle failures synchronously and give user feedback	Request-Response
Implementation Complexity	Higher — broker infrastructure, idempotency, ordering guarantees, and saga patterns add design complexity	Lower — well-understood HTTP/gRPC patterns with extensive framework support	Request-Response
Long-Running Operations	Ideal — fire-and-forget events trigger workflows that can run for hours without blocking callers	Poor fit — synchronous HTTP connections time out; requires polling or webhook callbacks for long jobs	Event-Driven

Decision Framework

When to Choose Each Option

Choose Event-Driven when...

Your operation involves multiple downstream services that should react to a state change independently and asynchronously
You are implementing a multi-step business workflow where individual steps can fail and retry without rolling back the entire process
You need to scale consumers independently of producers to handle variable processing loads
Your use case involves real-time data streaming, analytics ingestion, or continuous event processing
You want to decouple service teams so that adding a new consumer does not require changes to the producing service

Choose Request-Response when...

The end user or calling service needs an immediate, deterministic result to proceed — a login response, a search result, a form submission confirmation
Your operation requires reading strongly consistent state that must reflect the absolute latest data
The interaction is simple and point-to-point; the overhead of a message broker adds cost and complexity without benefit
You need rich, structured error responses that the caller can act on in real time (validation errors, authorization failures)
Your team is earlier in their distributed systems journey and needs a simpler programming model to maintain velocity

Not sure which is right for your project?

Use request-response for user-facing APIs, authentication flows, search queries, and any interaction requiring an immediate, consistent result. Use event-driven architecture for order processing workflows, notification pipelines, audit logging, data synchronization across services, and any multi-step process where individual steps can execute independently and failures should not cascade synchronously to the end user.

Related Resources

Related Services

Industries We Serve

Insights & Resources

Common Questions

Frequently Asked Questions

Yes, and they almost always should. Well-designed distributed systems use request-response for synchronous user interactions (APIs, queries) and event-driven patterns for background processing, cross-service workflows, and integrations. An e-commerce checkout might use a synchronous REST API to confirm the order to the user, then immediately publish an OrderPlaced event that triggers inventory reservation, payment capture, and fulfillment workflows asynchronously.

Work With Halkwinds

Ready to Make the Right Decision?

A 30-minute scoping call is enough to recommend the right approach for your specific context, budget, and timeline.

Browse All Comparisons