SQS vs SNS vs EventBridge — Messaging Service Comparison

Intermediate·2 min read·

Fast recall

Quick revision

Core answer

SQS is a pull-based durable queue for point-to-point messaging between services. SNS is a push-based pub/sub fanout service. EventBridge is an event bus with rich content-based routing, schema registry, and integrations with AWS services and SaaS providers. They are often combined: SNS fans out to SQS queues, or EventBridge routes events to SQS/Lambda targets.

Interview Answer2 min

SQS, SNS, and EventBridge are three different AWS messaging primitives — each designed for a different integration pattern. Choosing the wrong one for the job is a common architecture mistake.

SQS — durable queue, point-to-point

SQS holds messages until a consumer explicitly deletes them after processing — which means if the consumer crashes during processing, the message becomes visible again after the visibility timeout and can be reprocessed by another consumer
Standard queues provide at-least-once delivery; FIFO queues provide exactly-once delivery with ordering within a message group, at lower throughput
Use SQS when: one service produces work items and one service processes them; you need durability and retry on consumer failure; you don't need immediate fan-out to multiple consumers

SNS — push-based fan-out

SNS publishes one message to all registered subscribers simultaneously — SQS queues, Lambda functions, HTTP endpoints, email; which means one event published by a service can trigger multiple independent consumers without the producer knowing about them
SNS does not persist messages — if a subscriber is unavailable when the publish happens, the message is lost (unless the subscriber is an SQS queue, which buffers for it)
Use SNS when: one event must trigger multiple independent downstream workflows; fan-out is the pattern

EventBridge — content-based routing

EventBridge routes events from AWS services, custom applications, or SaaS partners to targets based on event content rules — source = "orders-service" AND detail.status = "PLACED" routes to one Lambda; detail.status = "CANCELLED" to another
EventBridge is the right choice when routing logic is complex, events come from multiple sources, or you want to decouple producers from consumers with schema-validated events via the Event Schema Registry

Common pattern: SNS + SQS fan-out

Producer publishes to SNS; multiple SQS queues subscribe — each consumer has its own queue, buffered and retried independently; this combines fan-out (SNS) with durability and retry (SQS)

Interview-ready guide

Interview answer

SQS, SNS, and EventBridge are three different AWS messaging primitives — each designed for a different integration pattern. Choosing the wrong one for the job is a common architecture mistake.

SQS — durable queue, point-to-point

SQS holds messages until a consumer explicitly deletes them after processing — which means if the consumer crashes during processing, the message becomes visible again after the visibility timeout and can be reprocessed by another consumer
Standard queues provide at-least-once delivery; FIFO queues provide exactly-once delivery with ordering within a message group, at lower throughput
Use SQS when: one service produces work items and one service processes them; you need durability and retry on consumer failure; you don't need immediate fan-out to multiple consumers

SNS — push-based fan-out

SNS publishes one message to all registered subscribers simultaneously — SQS queues, Lambda functions, HTTP endpoints, email; which means one event published by a service can trigger multiple independent consumers without the producer knowing about them
SNS does not persist messages — if a subscriber is unavailable when the publish happens, the message is lost (unless the subscriber is an SQS queue, which buffers for it)
Use SNS when: one event must trigger multiple independent downstream workflows; fan-out is the pattern

EventBridge — content-based routing

EventBridge routes events from AWS services, custom applications, or SaaS partners to targets based on event content rules — source = "orders-service" AND detail.status = "PLACED" routes to one Lambda; detail.status = "CANCELLED" to another
EventBridge is the right choice when routing logic is complex, events come from multiple sources, or you want to decouple producers from consumers with schema-validated events via the Event Schema Registry

Common pattern: SNS + SQS fan-out

Producer publishes to SNS; multiple SQS queues subscribe — each consumer has its own queue, buffered and retried independently; this combines fan-out (SNS) with durability and retry (SQS)

03 · Deep dive