Default to SQS Standard. Don’t overthink messaging architecture. A single SQS queue between your API and a worker Lambda covers 90% of early async needs.
Skip EventBridge until you have 3+ services producing events. For 1-2 services, direct SQS/SNS is simpler and cheaper.
Don’t build event-driven microservices yet. You’ll refactor your domain model 5 times before PMF. Monolith + SQS for background jobs is the right pattern.
EventBridge when you have 3+ services that react to the same business events. The content-based routing eliminates Lambda glue.
SNS + SQS fan-out for high-throughput notification patterns (>10K events/sec).
FIFO queues only when you have actual ordering bugs in production, not as a preventive measure. They cost more and have lower throughput (3,000 msg/sec with batching vs unlimited for Standard).
Synchronous is fine at startup scale. Don’t add SQS between your API and database “for decoupling” when you have 10 requests/second. It adds latency, complexity, and debugging difficulty. Add async when you have a specific scaling bottleneck.
EventBridge Archives are not a replacement for event sourcing. The replay is useful for debugging, not for rebuilding state. If you need event sourcing, use DynamoDB Streams or build a proper event store.
SQS FIFO’s exactly-once is per message-group, not per queue. If you thought FIFO makes your whole system exactly-once, you misunderstood it. You still need idempotent consumers for Standard OR FIFO.
DLQ without alerting is worse than no DLQ. It gives you false confidence that errors are “handled” when they’re actually just accumulating silently. Set up the CloudWatch alarm on DLQ message count ON THE SAME DAY you create the DLQ.