A Simple Idea That Still Holds Up
On July 13, 2006, Amazon launched SQS as one of its first three publicly available services. The problem it solved was basic but painful: when one service calls another directly and that other service is slow or down, failures cascade through an entire system. Message queuing broke that dependency by letting a producer drop a message into a queue and move on, while a consumer picked it up whenever it was ready. Two decades later, that same decoupling is still the reason companies reach for SQS, even as the scale and feature set around it have changed dramatically.
Fifteen Years, Then Five More
SQS's first fifteen years took it from an original 8 KB message limit through the addition of FIFO queues, server-side encryption, and Lambda integration. The five years since have pushed the service considerably further.
Throughput for FIFO queues climbed steadily: high-throughput mode launched supporting 3,000 transactions per second per API action, a tenfold jump over the prior ceiling, then rose again to 6,000, 9,000, and 18,000 TPS over the following two years, eventually reaching 70,000 TPS per API action in select regions.
Security defaults tightened too. Server-side encryption with SQS-managed keys arrived first as an option requiring no key management, then later became the default for every newly created queue, removing the need to opt in explicitly.
Recovering From Failure Got Easier
Dead-letter queue handling expanded step by step: redrive back to the source queue became available directly in the console, then extended to the SDK and CLI through new APIs, and finally gained support for FIFO queues specifically. Attribute-based access control arrived too, letting teams configure permissions using queue tags instead of maintaining static policies that get harder to manage as resources scale.
Other additions chipped away at real operational pain points: JSON protocol support in the SDK cut end-to-end processing latency by up to 23% for a 5 KB payload while lowering client-side CPU and memory use; direct EventBridge Pipes integration let messages route to a wide range of AWS targets without custom integration code; the Extended Client Library, previously Java-only, reached Python developers, allowing messages up to 2 GB by storing the payload in S3 and passing a reference through the queue; the in-flight message limit for FIFO queues grew sixfold, from 20,000 to 120,000; and fair queues arrived to stop a single noisy tenant in a multi-tenant standard queue from delaying delivery for everyone else, without requiring any consumer-side changes. Most recently, the maximum message payload doubled from 256 KiB to 1 MiB for both standard and FIFO queues.
The Same Pattern, New Workloads
Despite all that change, the core use case hasn't moved: decouple services, absorb bursts of traffic, and keep the rest of a system resilient when one part fails. What's new is who's using that pattern now. Companies increasingly rely on SQS queues to buffer requests to large language models, manage inference throughput under load, and coordinate communication between autonomous AI agents that operate as independent services talking to one another.
Twenty years on, the idea that made SQS useful on day one, don't let one slow or broken piece take down everything connected to it, turns out to be just as relevant to a fleet of AI agents as it was to the earliest AWS customers.