SNS fan-out

In 1 minute

One booking needs two things done later: an email and the QR tickets. The api does not send to each worker. It publishes one “booking confirmed” event to an SNS topic (Simple Notification Service), and the topic delivers a copy to every subscriber. Each subscriber is an SQS queue with its own consumer, so email and tickets succeed, fail and retry on their own.

Picture it

flowchart TB
  R["outbox relay"] -->|"Publish once"| T["SNS topic<br/>minitickets-dev-booking-events"]
  T -->|"copy"| J["SQS jobs queue<br/>(email)"]
  T -->|"copy"| K["SQS tickets queue"]
  J --> W["worker Lambda"]
  K --> L["tickets Lambda"]

How it works

1. Publish once. The outbox relay calls Publish on the topic with the message as JSON.
2. SNS copies. The topic has two subscriptions (a subscription = “deliver copies to this endpoint”), both with protocol sqs: the jobs queue and the tickets queue.
3. Raw delivery. rawMessageDelivery is on, so each queue receives exactly the JSON the api sent, not wrapped in an SNS envelope. The consumers parse one shape.
4. The queue must allow SNS in. Each queue has a resource policy (a policy attached to the resource, saying who may use it): sns.amazonaws.com may sqs:SendMessage, only when aws:SourceArn is this topic and aws:SourceAccount is ours.
5. Each consumer runs alone. A broken email path does not stop tickets, and the other way round.

In MiniTickets

Everything is in infra/src/jobs/booking-events.ts → createBookingEvents. Each subscription is created only after its queue policy exists (dependsOn), because SNS would otherwise fail to deliver. The topic ARN is handed to the api only when both subscriptions exist: SNS happily accepts a message with zero subscribers, and the relay would then mark an undelivered row as sent.

The topic is always on: it costs nothing while idle. The api task role may sns:Publish on this one topic only.

From → to	What happens	What allows it
Transactional outbox → Booking-events SNS topic	the relay publishes each pending row once to SNS	code relayOnce → publishBookingConfirmed (PublishCommand, maxAttempts 1)publishBookingConfirmed
API ECS service → Booking-events SNS topiconly when computeEnabled = true	the outbox relay publishes each booking-confirmed event	iam api task role, policy send-jobs: sns:Publish on minitickets-dev-booking-events onlycreateIamRoles route public route table: 0.0.0.0/0 → minitickets-dev-igw. The task has a public IP; there is no NAT gateway and no VPC endpoint.createNetwork
Booking-events SNS topic → Jobs SQS queue	SNS delivers a copy to the email queue	resource-policy queue policy: sns.amazonaws.com may sqs:SendMessage on this queue, only when aws:SourceArn is the topic and aws:SourceAccount is ourscreateBookingEvents trigger SNS subscription protocol sqs, rawMessageDelivery truecreateBookingEvents
Booking-events SNS topic → Tickets SQS queue	SNS delivers a copy to the tickets queue	resource-policy queue policy: sns.amazonaws.com may sqs:SendMessage on this queue, only when aws:SourceArn is the topic and aws:SourceAccount is ourscreateBookingEvents trigger SNS subscription protocol sqs, rawMessageDelivery truecreateBookingEvents

See the topic and its two queues on the map →

See it in AWS

Console

SNS → Topics → minitickets-dev-booking-events → Subscriptions: two, protocol SQS, status Confirmed.

CLI

aws sns list-subscriptions-by-topic --topic-arn <booking-events-topic-arn>

Code

The queue policies and subscriptions: infra/src/jobs/booking-events.ts → createBookingEvents.

Break it

Symptom	Cause	Where to look
The relay logs “accepted by SNS”, but the queues stay empty	A queue policy does not allow sns.amazonaws.com from this topic	SQS → queue → Access policy
Tickets arrive but emails do not	One subscription is missing or points at another queue	SNS → topic → Subscriptions
The worker rejects every message as invalid	Raw delivery is off: the message arrives inside the SNS envelope	Subscription → Raw message delivery

Say it in an interview

Say it like this (20-30 seconds)

The api publishes each booking-confirmed event once to an SNS topic. The topic has two SQS subscriptions with raw message delivery, one for email and one for tickets. Each queue’s resource policy lets only SNS send, and only from this topic in our account. The api never knows who listens, and each consumer has its own queue, retries and dead-letter queue, so one failing consumer never blocks the other.

Follow-ups

Why not let the Lambdas subscribe to SNS directly?

SNS would call them at once and retry on its own schedule. A queue in between holds messages while a consumer is down or slow, and gives each consumer batching, backoff and a DLQ.

How would you add a third consumer, for example analytics?

One more queue, its queue policy and one more subscription. The api and the other consumers do not change.

SNS or EventBridge?

EventBridge adds content-based routing rules, schemas and many targets. For one event type and two queues, SNS is simpler. It is a reasonable change if event types and routing rules grow.

Advanced: Details: ordering and duplicates

The topic and queues are standard (not FIFO). Delivery is at least once and in no fixed order. That is fine here: each message is about one booking, and both consumers are idempotent by booking id.

Checkpoint

Answer these without scrolling up. If one feels hard, reread that section.

1. How many times does the api publish one booking event?
2. What does rawMessageDelivery change?
3. Which two conditions does each queue policy check?
4. Why does the api get the topic ARN only after both subscriptions exist?
5. Why put a queue between SNS and each Lambda?

Redraw it from memory: outbox relay → SNS topic → (jobs queue → worker Lambda) and (tickets queue → tickets Lambda)

Try this: on the map, select the booking-events SNS topic, open Connections, and find the rule that lets SNS send to each queue

Mark this page as read