--- title: "When to Mix SQS FIFO and Standard Queues in an Agent Pipeline" canonical_url: "https://cognilium.ai/blogs/sqs-fifo-vs-standard-agent-pipeline-design" slug: "sqs-fifo-vs-standard-agent-pipeline-design" section: "blogs" date_published: "2026-05-05" date_modified: "2026-05-05" word_count: 1400 reading_time_minutes: 7 author: "Mudassir Marwat" author_identifier: "0009-0008-1927-2598" person_same_as: - "https://www.linkedin.com/in/mudassir-marwat/" - "https://orcid.org/0009-0008-1927-2598" - "https://github.com/mudassirmarwat" - "https://medium.com/@mudassir-marwat" - "https://www.youtube.com/@mudassir-marwat" - "https://dev.to/mudassirmarwat" - "https://hashnode.com/@mudassirmarwat" - "https://huggingface.co/mudassirmarwat" - "https://bsky.app/profile/mudassir-marwat.bsky.social" - "https://substack.com/@mudassirmarwat" - "https://topmate.io/mudassirmarwat" - "https://fueler.io/mudassirmarwat" - "https://www.instagram.com/mudassirmarwat/" - "https://www.facebook.com/mudassir.marwat" - "https://www.reddit.com/user/mudassirmarwat/" - "https://www.f6s.com/member/mudassir-marwat" - "https://cognilium.ai/founder" entities: [] related: - "https://cognilium.ai/blogs/agent-pipeline-failure-recovery-dynamodb-sqs" - "https://cognilium.ai/blogs/google-adk-supervisor-multi-tenant-tool-registration" - "https://cognilium.ai/blogs/multi-agent-orchestration-aws" - "https://cognilium.ai/blogs/bias-detection-multi-agent-evaluation" --- # When to Mix SQS FIFO and Standard Queues in an Agent Pipeline FIFO for chunk ordering, Standard for parallel analysis fan-out. Why a single queue type for the whole pipeline is the wrong default, with the dead-letter and retry settings that make the split work. ## Key takeaways - One queue type for a whole pipeline is the wrong default. Ordering and throughput are different requirements, and they change per stage. - FIFO where sequence carries meaning; Standard where work fans out and order does not matter. - An assembly stage needs explicit deduplication, because Standard delivery is at-least-once. - Dead-letter settings belong per queue — a poison message during extraction is not the same failure as one during analysis. An agent pipeline with multiple stages tends to default to one queue type for the whole topology. That works for tutorials and breaks at production scale. The pipeline this writeup describes has three queue boundaries and uses three different topology choices for them — and the reasoning is worth writing down because most teams hit this and pick the wrong default. ## Stage 1: chunk extraction (FIFO) A document is split into 50–100 chunks. The assembler downstream stitches them into a structured contract analysis. Chunks must arrive in order — chunk 7 cannot land before chunk 6, otherwise the assembler either reorders (expensive) or skips and waits (slow). FIFO with message group ID = job_id keeps order inside one job while different jobs run in parallel. Per-group throughput is 300 messages/sec without batching, 3,000 with — enough for a job that emits 100 chunks in a couple seconds. ## Stage 2: analysis fan-out (Standard) Each chunk fans out to 11 specialist analyst agents. There is no ordering relationship — bias, severity, ambiguity, party, and the rest can finish in any order; the merger just collects them. FIFO here would force per-group serialization and tank parallelism. Standard queue with at-least-once delivery + idempotent worker is the right call. ## Stage 3: result assembly (Standard with deduplication) Results from 11 agents per chunk merge back. Standard works because the merge step is idempotent — writing the same agent result twice produces the same output. The trick: each merge writes to DynamoDB with a conditional update on (chunk_id, agent_id). Duplicate deliveries hit the conditional and short-circuit. ## Dead-letter settings per queue - FIFO chunk queue: maxReceiveCount = 3, DLQ retention 14 days. A wedged chunk blocks its group — fail fast and alert. - Standard analysis queue: maxReceiveCount = 10, retention 14 days. Leaf-level retries are cheap, model-side rate limits resolve naturally. - Standard merge queue: maxReceiveCount = 5, retention 7 days. Failures here usually mean a chunk_id has been deleted from DynamoDB — short DLQ, fast triage. ## When to ignore this advice Pipelines with fewer than ~50 messages per request rarely justify the topology split — the operational overhead of three queue types and three DLQ alerts costs more than reordering at the assembler. The split earns its keep when one job emits 1,000+ messages and a single bad message must not block the rest. ## What we measured - 22 chunks per contract → 22 FIFO messages → ~5 sec to drain - 22 chunks × 11 agents = 242 Standard messages → ~25 sec parallel processing - DLQ rate steady-state: <0.1% of messages - P95 end-to-end: 154 sec from upload to assembled report ## Frequently asked questions ### Why not Standard for everything? FIFO is slower. FIFO is slower per message (300/s per group ID without batching). But for the chunk-extraction stage, ordering inside a job matters — the assembler downstream expects chunks in order. Reordering at the assembler is more expensive than the FIFO penalty. ### Why not FIFO for everything? Ordering is always nice. FIFO collapses to per-group serialization. For the analysis stage, 11 specialist agents fan out per chunk — they have no inter-chunk ordering requirement and you want all 11 running simultaneously. FIFO would queue them by group ID and lose your parallelism. ### What goes in the message group ID? For chunk extraction: job_id. All chunks for one job stay ordered; different jobs run in parallel. For other FIFO stages where ordering scope differs, pick the smallest natural ordering unit. ### How big can these messages get? SQS limit is 256KB per message. We keep ChunkMessage under that with the chunk text capped at 900KB stored in S3 — the message carries the S3 key. Related-terms list capped at 50 to bound the post-processing fan-out. ### DLQ thresholds — why different per queue? FIFO chunk queue: DLQ after 3 receives. Standard analysis queue: DLQ after 10. The FIFO queue is upstream and a bad message there blocks its group; you want it out fast. The analysis queue is leaf-level — re-tries are cheap and fan-out tolerates more before declaring dead. --- Canonical HTML: https://cognilium.ai/blogs/sqs-fifo-vs-standard-agent-pipeline-design