SNS vs Dedicated Services. CAP theorem tradeoffs
The brutal CAP theorem tradeoffs between AWS SNS/SQS and custom event services that nobody talks about
Every microservices team eventually hits the same architectural crossroads: deploy AWS SNS/SQS and call it a day, or build a custom event service that promises better guarantees. The choice isn’t about convenience, it’s about which CAP theorem compromise you’re willing to live with.
The Event Distribution Dilemma: Managed vs Custom
When a user purchase event fires, your architecture decides whether three different services receive the notification instantly, eventually, or not at all. AWS SNS/SQS offers the path of least resistance: managed infrastructure, automatic scaling, and someone else’s pager duty. The custom event service route promises something more valuable, control over delivery semantics, ordering guarantees, and business logic during distribution.
The real question isn’t which approach is better, but which failure mode you’d rather debug at 3 AM.
CAP Theorem’s Brutal Reality Check
The research reveals the fundamental tradeoff: SNS/SQS prioritizes availability and partition tolerance at the cost of consistency, while custom event services prioritize consistency and partition tolerance at the cost of availability.
AWS SNS delivers at-least-once semantics with possible duplicates and no ordering guarantees. It’s the “I’d rather deliver a message twice than lose it completely” philosophy. Your e-commerce order might get processed multiple times, but at least the order doesn’t vanish into the ether.
Custom event services can achieve exactly-once delivery and strict ordering, but you own the infrastructure, scaling, and that single point of failure. When your financial transaction service goes down during deployment, nobody processes payments until you fix it.
The Operational Debt Nobody Calculates
The SNS/SQS approach masks its complexity in operational simplicity. Teams can add consumers without coordination, scaling happens automatically, and AWS manages the infrastructure. But you inherit 256KB message limits, unconfigurable retry mechanisms, and vendor lock-in that makes future migration painful.
Building your own event service means writing complex retry/error handling, implementing idempotency across services, and maintaining what essentially becomes a custom message broker. As one architect noted, “With the effort you’d spend on retrying and acknowledgement mechanisms in your custom event service, you could end up with similar guarantees if you were to instead familiarize yourself with and build around an off-the-shelf event solution.”
Real-World Consequences: Duplicates vs Drops
The debate crystallizes around one practical question: “Which problem do I think is easier to manage? Handling event drops or duplicate events?”
Financial systems typically choose the custom event service path, duplicate $100 transactions could be catastrophic. E-commerce platforms often prefer SNS/SQS, sending two confirmation emails beats sending none. But as one commenter pointed out, “Handling event drop will be tough to handle. Because in case of duplication you can still merge record or delete one record… In case of drop if you can handle retrial logic then might be easy.”
The irony? Most teams spend more time building deduplication logic than they would implementing robust retry mechanisms.
Beyond CAP: The PACELC Extension
The CAP theorem only tells part of the story. The PACELC theorem extends this thinking: during partitions (P), you trade off availability vs consistency (A vs C), but during normal operations (E), you trade off latency vs consistency (L vs C).
SNS/SQS optimizes for low latency during normal operations, accepting eventual consistency. Custom event services can prioritize strong consistency, accepting higher latency for coordination. This explains why systems like Amazon DynamoDB (AP/EL) prioritize availability during partitions and latency over consistency during normal operations, while Google Spanner (CP/EC) chooses consistency during partitions and consistency over latency during normal operations.
The Vendor Lock-In Trap
AWS EventBridge has emerged as a middle ground, offering more sophisticated routing, schema discovery, and cross-account event delivery. But it’s still AWS, another form of vendor lock-in that makes the custom service approach more appealing for multi-cloud strategies.
The architectural decision ultimately reflects your organization’s tolerance for vendor dependence versus operational complexity. There’s no right answer, only the answer that aligns with your business constraints and engineering culture.
Most teams choose SNS/SQS because operational overhead is immediate and tangible, while consistency issues are deferred and abstract. They’ll deal with duplicate orders tomorrow to avoid being paged about infrastructure tonight.
The custom event service advocates are playing the long game, accepting short-term pain for long-term correctness. They’re building the foundation for financial-grade reliability while the SNS teams are patching over idempotency bugs.
In the end, both approaches converge on the same realization: distributed systems force tradeoffs, and the only wrong choice is pretending you can avoid them.
