Why put SNS before two SQS queues instead of letting both workers share one queue?

Say it in 30 seconds

Say it like this (20-30 seconds)

SNS gives each consumer its own copy of a booking event. Separate SQS queues then buffer email and ticket generation independently. If both workers shared one queue, they would compete for messages rather than both receive every booking. MiniTickets uses raw SNS delivery to preserve the message JSON. The trade-off is more subscriptions, policies and failure paths to monitor; a successful publish does not prove that either consumer completed its work.

The deeper answer

The API publishes one versioned booking event. The infrastructure subscribes the email queue and tickets queue to the topic. Each queue has a resource policy allowing SNS to send from this exact topic and account. The workers have separate queue-reading permissions and separate failure queues.

This isolates a slow or broken email path from ticket generation. Queue retention still bounds the outage the system can absorb; buffering is not infinite storage. Consumers also validate their message contracts because persisted events may outlive a deployment.

The topic output waits for both subscriptions to exist before the publisher configuration uses it. That avoids starting a publisher with no routes during normal provisioning. It does not prove that a later policy change or subscription deletion cannot break delivery. Production verification should follow a known booking across both paths, not stop at the SNS acceptance log.

Counter-questions

What if raw delivery is switched off?

The SQS body becomes an SNS envelope rather than the booking object expected by the handlers. Schema validation fails until the delivery format or consumer is corrected.

Why not call both queues from the API?

That creates two independent publish outcomes in the request path or relay. SNS centralizes fan-out, though its subscription delivery still needs policies, observability and recovery planning.

How do you find one missing consumer?

Compare the topic subscriptions and each queue policy, then queue age, delivery failures and worker logs. A healthy ticket path cannot prove the email subscription is healthy.

Where in MiniTickets

Read Sns fan out, then inspect the booking-events-topic piece →.

infra/src/jobs/booking-events.ts → createBookingEvents

See the SNS delivers nothing case.