{
  "schemaVersion": 1,
  "id": "atlas-lesson-event-queues-delivery",
  "title": "Events, queues and backpressure",
  "category": "learning",
  "format": "Atlas lesson",
  "description": "Distinguish event occurrence, delivery, acknowledgement, deduplication, retries and admission.",
  "canonicalUrl": "https://semiaifoundry.com/learn/atlas/event-queues-delivery/",
  "publishedDate": null,
  "revisionDate": "2026-10-07",
  "author": null,
  "topic": "From request to durable action",
  "series": null,
  "license": null,
  "rightsUrl": "https://semiaifoundry.com/ai-atlas/licenses.html",
  "version": "1.3.0",
  "status": "Published educational lesson",
  "evidenceScope": "The durable incident experience executes typed fixture tools, authority checks, exact review, receipts and independent final-state checks. Its policies are authored code and its storage boundary is local; it is not a real model or production workflow platform. The quantities and fixtures are authored. Source scope is recorded in the automation learning review manifest; no source benchmark or private system behavior is claimed. Counts share one queue boundary. Admissions and duplicate removals cannot exceed available queued deliveries. Business effects are counted separately.",
  "contentCoverage": "published-lesson",
  "artifactUrl": "https://semiaifoundry.com/ai-atlas/lesson-data/event-queues-delivery-c2f047356ab0b24d.json",
  "interactiveUrl": "https://semiaifoundry.com/ai-atlas/#event-queues-delivery",
  "related": [],
  "supersedes": [],
  "supersededBy": [],
  "contentHash": "04d57892306a037cf0ebbaa95c17de8d5af35e3964f6c25a5747209a8db19c34",
  "contentLength": 6518,
  "jsonUrl": "https://semiaifoundry.com/agents/publications/atlas-lesson-event-queues-delivery.json",
  "markdownUrl": "https://semiaifoundry.com/agents/publications/atlas-lesson-event-queues-delivery.md",
  "sections": [
    {
      "id": "section-1",
      "title": "Events, queues and backpressure",
      "start": 47,
      "end": 464
    },
    {
      "id": "section-2",
      "title": "The mechanism",
      "start": 464,
      "end": 1795
    },
    {
      "id": "section-3",
      "title": "Science and assumptions",
      "start": 1795,
      "end": 1823
    },
    {
      "id": "section-4",
      "title": "Events, queues and backpressure · explicit relationship",
      "start": 1823,
      "end": 2922
    },
    {
      "id": "section-5",
      "title": "Engineering example",
      "start": 2922,
      "end": 3440
    },
    {
      "id": "section-6",
      "title": "Distinctions and tradeoffs",
      "start": 3440,
      "end": 3801
    },
    {
      "id": "section-7",
      "title": "Specifications and interfaces",
      "start": 3801,
      "end": 4353
    },
    {
      "id": "section-8",
      "title": "Interfaces",
      "start": 4353,
      "end": 4628
    },
    {
      "id": "section-9",
      "title": "Check your understanding",
      "start": 4628,
      "end": 4657
    },
    {
      "id": "section-10",
      "title": "Two copies of the same incident arrive; one is admitted and one is deduplicated. How many distinct incidents were executed?",
      "start": 4657,
      "end": 4961
    },
    {
      "id": "section-11",
      "title": "Evidence and scope",
      "start": 4961,
      "end": 5829
    },
    {
      "id": "section-12",
      "title": "Sources",
      "start": 5829,
      "end": 6184
    },
    {
      "id": "section-13",
      "title": "Continue exploring",
      "start": 6184,
      "end": 6207
    },
    {
      "id": "section-14",
      "title": "Foundations",
      "start": 6207,
      "end": 6328
    },
    {
      "id": "section-15",
      "title": "Related lessons",
      "start": 6328,
      "end": 6518
    }
  ],
  "citations": [
    {
      "title": "Explore in Atlas",
      "url": "https://semiaifoundry.com/ai-atlas/#event-queues-delivery"
    },
    {
      "title": "Temporal Activities",
      "url": "https://docs.temporal.io/activities"
    },
    {
      "title": "Temporal Workflow Execution",
      "url": "https://docs.temporal.io/workflow-execution"
    },
    {
      "title": "Published lesson data",
      "url": "https://semiaifoundry.com/ai-atlas/lesson-data/event-queues-delivery-c2f047356ab0b24d.json"
    },
    {
      "title": "Atlas releases and licensing",
      "url": "https://semiaifoundry.com/ai-atlas/licenses.html"
    },
    {
      "title": "Workflow graphs and explicit state",
      "url": "https://semiaifoundry.com/learn/atlas/workflow-graphs-state/"
    },
    {
      "title": "Tools, memory & agent loop",
      "url": "https://semiaifoundry.com/learn/atlas/tool-loop/"
    },
    {
      "title": "Evaluation & the AGI frontier",
      "url": "https://semiaifoundry.com/learn/atlas/evaluation/"
    }
  ],
  "recordHash": "fd617b74efa53407faeb159b3a43b3077b371136e2df483460c0e77cfc5e0e79",
  "contentFormat": "text/markdown",
  "content": "From request to durable action · Atlas v1.3.0\n\n# Events, queues and backpressure\n\nDistinguish event occurrence, delivery, acknowledgement, deduplication, retries and admission.\n\n[Explore in Atlas](https://semiaifoundry.com/ai-atlas/#event-queues-delivery)Logical state, task evidence and declared units; no physical assembly scale\n\nLearning objectiveReconcile arrivals, admissions and duplicate removals without confusing deliveries with distinct business tasks.\n\n## The mechanism\n\nAn event describes something that occurred; a delivery is one attempt to bring that event to a consumer. Networks, acknowledgements and worker failures can cause repeated or delayed deliveries. A queue therefore holds deliveries, while the consumer may track stable business event identities. Admission moves a delivery into service; deduplication can remove a repeated identity without repeating its effects. Queue length alone says nothing about unique useful work. A retry policy must also distinguish a request that never started from one whose acknowledgement was lost. In the incident experience two simultaneous deliveries name the same incident. One worker handles it, then acknowledges the remaining duplicate without another reservation. This is a bounded single-consumer example; it does not implement a general distributed queue or prove exactly-once delivery.\n\n1.  A stable event identity accompanies each delivery, separately from its arrival attempt.\n2.  The queue balance records arrivals, admissions into service and discarded duplicates at one declared boundary.\n3.  The consumer checks whether a delivery belongs to an already handled incident before beginning another workflow.\n4.  A durable effect still needs its own idempotency protection because a consumer may fail after service starts.\n\n## Science and assumptions\n\n### Events, queues and backpressure · explicit relationship\n\n$$\nQ_{k+1}=Q_k+A_k-C_k-D_k\n$$\n\nQueued deliveries equal the previous queue plus arrivals, minus admissions into service and duplicate removals.\n\nSymbols and units\n\nQₖ\n\nQueued delivery count at interval boundary k\n\ndeliveries\n\nAₖ\n\nArrivals during the interval\n\ndeliveries\n\nCₖ\n\nDeliveries admitted into service\n\ndeliveries\n\nDₖ\n\nQueued duplicates removed without service\n\ndeliveries\n\nStart with an empty queue and deliver incident-017 twice. The queue contains two deliveries. Admission removes one, leaving one waiting while the worker makes four normal tool calls. After completion, deduplication removes the second delivery, so the queue returns to zero. Exactly one reservation and one work order exist. Two arrivals minus one admission minus one duplicate removal equals zero queued deliveries; counting deliveries as two successful incidents would overstate useful work.\n\nAssumptions Counts share one queue boundary. Admissions and duplicate removals cannot exceed available queued deliveries. Business effects are counted separately.\n\n## Engineering example\n\nStart with an empty queue and deliver incident-017 twice. The queue contains two deliveries. Admission removes one, leaving one waiting while the worker makes four normal tool calls. After completion, deduplication removes the second delivery, so the queue returns to zero. Exactly one reservation and one work order exist. Two arrivals minus one admission minus one duplicate removal equals zero queued deliveries; counting deliveries as two successful incidents would overstate useful work.\n\n## Distinctions and tradeoffs\n\nAn acknowledgement retry does not necessarily represent a new task.\n\nRetaining deduplication identity uses state and needs an explicit retention scope; removing it too soon can permit old deliveries to repeat work.\n\nWebhook-driven and tool-driven AI services face the same event-delivery ambiguity as other asynchronous systems.\n\n## Specifications and interfaces\n\nMechanism boundary\n\nWhy does one event sometimes arrive twice?\n\nCounts share one queue boundary. Admissions and duplicate removals cannot exceed available queued deliveries. Business effects are counted separately.\n\nEvidence type\n\nAuthored worked example\n\nThe durable incident experience executes typed fixture tools, authority checks, exact review, receipts and independent final-state checks. Its policies are authored code and its storage boundary is local; it is not a real model or production workflow platform.\n\n### Interfaces\n\nDeclared input and state Input\n\nA stable event identity accompanies each delivery, separately from its arrival attempt.\n\nChecked outcome Output\n\nReconcile arrivals, admissions and duplicate removals without confusing deliveries with distinct business tasks.\n\n## Check your understanding\n\n### Two copies of the same incident arrive; one is admitted and one is deduplicated. How many distinct incidents were executed?\n\n1.  Two\n2.  One\n3.  Zero because a duplicate is an error\n\nAnswer and reasoning\n\nOne\n\nThe stable incident identity is the same on both deliveries; only one workflow executes.\n\n## Evidence and scope\n\nThe durable incident experience executes typed fixture tools, authority checks, exact review, receipts and independent final-state checks. Its policies are authored code and its storage boundary is local; it is not a real model or production workflow platform. The quantities and fixtures are authored. Source scope is recorded in the automation learning review manifest; no source benchmark or private system behavior is claimed. Counts share one queue boundary. Admissions and duplicate removals cannot exceed available queued deliveries. Business effects are counted separately.\n\nThe durable incident experience executes typed fixture tools, authority checks, exact review, receipts and independent final-state checks. Its policies are authored code and its storage boundary is local; it is not a real model or production workflow platform.\n\n## Sources\n\n-   [Temporal Activities](https://docs.temporal.io/activities)\n-   [Temporal Workflow Execution](https://docs.temporal.io/workflow-execution)\n\n[Published lesson data](https://semiaifoundry.com/ai-atlas/lesson-data/event-queues-delivery-c2f047356ab0b24d.json) · [Atlas releases and licensing](https://semiaifoundry.com/ai-atlas/licenses.html)\n\n## Continue exploring\n\n### Foundations\n\n-   [Workflow graphs and explicit state](https://semiaifoundry.com/learn/atlas/workflow-graphs-state/)\n\n### Related lessons\n\n-   [Tools, memory & agent loop](https://semiaifoundry.com/learn/atlas/tool-loop/)\n-   [Evaluation & the AGI frontier](https://semiaifoundry.com/learn/atlas/evaluation/)"
}