WEB / WEB-19.02

Queues, producers, consumers, and workers

A public-note background indexing job enters a queue; delivery, business results, and acknowledgements remain distinct states.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

Commit then ack

Prepare job
The producer prepares job-note-1 with jobId, kind=index-public-note and noteId=tea. Queue and worker are local adapters here; publication, delivery and business commit have not occurred.
Producer / application
Job-note-1 prepared
Selected local queue
Pending0; inflight0
Consumer / worker
No delivery
Business database
Result0; marker0
Queue accepts
The selected queue retains pending work; accepted publication is neither a business result nor real broker confirm.
Producer / application
Job-note-1 prepared
Selected local queue
Pending1; inflight0
Consumer / worker
No delivery
Business database
Result0; marker0
Consumer delivery
Local delivery moves pending work into inflight and the worker receives it; no network arrival is claimed.
Producer / application
Job-note-1 prepared
Selected local queue
Pending0; inflight1
Consumer / worker
Job-note-1 delivery1
Business database
Result0; marker0
Validate job
The worker validates known kind/noteId/jobId fields; message data is not executed as code.
Producer / application
Job-note-1 prepared
Selected local queue
Pending0; inflight1
Consumer / worker
Known job schema valid
Business database
Result0; marker0
Business commit
The result and processed marker commit together in the selected database; queue inflight is separate state.
Producer / application
Job-note-1 prepared
Selected local queue
Pending0; inflight1
Consumer / worker
Known job schema valid
Business database
Result1; marker1
Manual ack intent
After commit the worker prepares acknowledgement intent; acknowledgement does not inspect the database commit itself.
Producer / application
Job-note-1 prepared
Selected local queue
Pending0; inflight1
Consumer / worker
Committed result; ack intent
Business database
Result1; marker1
Queue ack applies
The local adapter completes acknowledgement and removes inflight; no real broker/network receipt runs here.
Producer / application
Job-note-1 prepared
Selected local queue
Pending0; inflight0
Consumer / worker
Committed result; ack intent
Business database
Result1; marker1
Job outcome known
The selected ledger records result and delivery lifecycles separately; HTTP caller receipt is not proved.
Producer / application
Selected business result available
Selected local queue
Pending0; inflight0
Consumer / worker
Committed result; ack intent
Business database
Result1; marker1

Commit/ack gap

Prepare job
The producer prepares a known public-note job as inert data; the native queue is a finite local adapter.
Producer / application
Job-note-1 prepared
Selected local queue
Pending0; inflight0
Consumer / worker
No delivery
Business database
Result0; marker0
Queue accepts
The selected queue retains pending work; accepted publication is neither a business result nor real broker confirm.
Producer / application
Job-note-1 prepared
Selected local queue
Pending1; inflight0
Consumer / worker
No delivery
Business database
Result0; marker0
Consumer delivery
Local delivery moves pending work into inflight and the worker receives it; no network arrival is claimed.
Producer / application
Job-note-1 prepared
Selected local queue
Pending0; inflight1
Consumer / worker
Job-note-1 delivery1
Business database
Result0; marker0
Business commit
The result and processed marker commit in one SQLite transaction; acknowledgement has not yet been applied.
Producer / application
Job-note-1 prepared
Selected local queue
Pending0; inflight1
Consumer / worker
Job-note-1 delivery1
Business database
Result1; marker1
Stop/requeue
An injected consumer stop returns unacked work to local pending; the business commit is not undone.
Producer / application
Job-note-1 prepared
Selected local queue
Pending1; inflight0
Consumer / worker
Job-note-1 delivery1
Business database
Result1; marker1
Second delivery
Job-note-1 is delivered again; the same business job ID belongs to a different selected delivery instance.
Producer / application
Job-note-1 prepared
Selected local queue
Pending0; inflight1
Consumer / worker
Job-note-1 delivery2
Business database
Result1; marker1
Marker found
A committed marker lookup skips the duplicate effect; resultRows remains1 and external effects are excluded.
Producer / application
Job-note-1 prepared
Selected local queue
Pending0; inflight1
Consumer / worker
Job-note-1 delivery2
Business database
Existing marker; result1 preserved
Second ack applies
The worker acknowledges after the duplicate-safe result; local inflight clears without a universal exactly-once claim.
Producer / application
Job-note-1 prepared
Selected local queue
Pending0; inflight0
Consumer / worker
Job-note-1 delivery2
Business database
Existing marker; result1 preserved

Early ack stop

Prepare job
The producer prepares a known public-note job as inert data; the native queue is a finite local adapter.
Producer / application
Job-note-1 prepared
Selected local queue
Pending0; inflight0
Consumer / worker
No delivery
Business database
Result0; marker0
Queue accepts
The selected queue retains pending work; accepted publication is neither a business result nor real broker confirm.
Producer / application
Job-note-1 prepared
Selected local queue
Pending1; inflight0
Consumer / worker
No delivery
Business database
Result0; marker0
Consumer delivery
Local delivery moves pending work into inflight and the worker receives it; no network arrival is claimed.
Producer / application
Job-note-1 prepared
Selected local queue
Pending0; inflight1
Consumer / worker
Job-note-1 delivery1
Business database
Result0; marker0
Early ack intent
The worker chooses early acknowledgement before business commit, exposing the selected policy failure boundary.
Producer / application
Job-note-1 prepared
Selected local queue
Pending0; inflight1
Consumer / worker
Ack intent; no business result
Business database
Result0; marker0
Queue ack applies
The local adapter applies acknowledgement and clears inflight; no SQL result or marker exists yet.
Producer / application
Job-note-1 prepared
Selected local queue
Pending0; inflight0
Consumer / worker
Ack intent; no business result
Business database
Result0; marker0
Injected stop
An authored worker stop occurs before the business operation; an empty queue cannot prove completion.
Producer / application
Job-note-1 prepared
Selected local queue
Pending0; inflight0
Consumer / worker
Stopped before business commit
Business database
Result0; marker0
Result absent
Independent result lookup sees zero rows and markers; the selected queue policy no longer retains the job.
Producer / application
Job-note-1 prepared
Selected local queue
Pending0; inflight0
Consumer / worker
Stopped before business commit
Business database
Result0; marker0

Outbox relay gap

Outbox intent
The producer chooses to prepare its note update and event intent in the same selected database transaction.
Producer / application
Producer transaction prepared
Selected local queue
Pending0; inflight0
Consumer / worker
No delivery
Business database
Note version1; outbox0
Pending SQL state
Note version2 and its outbox row are pending in one transaction; the relay does not publish uncommitted events.
Producer / application
Producer transaction prepared
Selected local queue
Pending0; inflight0
Consumer / worker
No delivery
Business database
Pending note2; pending outbox1
Commit both
Explicit COMMIT exposes both database rows together; no queue publication has occurred yet.
Producer / application
Producer transaction prepared
Selected local queue
Pending0; inflight0
Consumer / worker
No delivery
Business database
Committed note2; pending outbox1
Relay reads intent
The relay selects the committed pending outbox row through an independent read and prepares known job data.
Producer / application
Relay selected job-note-1
Selected local queue
Pending0; inflight0
Consumer / worker
No delivery
Business database
Committed note2; pending outbox1
Publish accepted
The own finite queue accepts the pending job; the database sent marker does not update in this owner.
Producer / application
Relay selected job-note-1
Selected local queue
Pending1; inflight0
Consumer / worker
No delivery
Business database
Committed note2; pending outbox1
Relay gap
An injected relay stop follows publication but precedes the sent marker; queue and database knowledge differ.
Producer / application
Stopped before sent marker
Selected local queue
Pending1; inflight0
Consumer / worker
No delivery
Business database
Committed note2; pending outbox1
Pending still seen
An independent database read sees note2 and one sent=false event; this does not prove no publication occurred.
Producer / application
Stopped before sent marker
Selected local queue
Pending1; inflight0
Consumer / worker
No delivery
Business database
Note2; outbox1 sent=false
Retry publishes
The selected relay retry publishes the same job again; consumer idempotency and job-identity scope still matter.
Producer / application
Stopped before sent marker
Selected local queue
Pending2; duplicate job identity
Consumer / worker
No delivery
Business database
Note2; outbox1 sent=false

ACTORS · STATE · DATA FLOW

When and for whom does a queue retain work?

A producer prepares a job description as a message: job-note-1 requests indexing for public note tea. The queue retains selected pending work; a consumer receives it and a worker executes application logic. These roles can share a process or use separate services. This worker is an application background-task component, not the browser Web Worker or Service Worker runtime API. Having a queue proves neither completion nor HTTP caller receipt.

A background job separates lengthy or deferred work from request lifetime. Accepted/pending status communicates that work remains; scheduled work may still fail. Concurrency, capacity, and prefetch influence outstanding deliveries per worker, but this lesson offers no production tuning numbers. The native queue adapter processes one finite job using pending/inflight lists, not a network broker or parallel workers. Its known public-note schema is inert data, not imported code.

The selected message contains jobId, kind, and noteId. The application chooses jobId as a business idempotency key. A RabbitMQ delivery tag instead identifies a delivery within a channel and is not the job identity. Redelivery can have a different delivery identity. There are no universal queue-capacity or payload-size values. Our fixture validates purpose/shape and observes an independent result row; job data does not substitute for permission decisions.

Which boundaries do acknowledgements and commits cross?

Publisher confirms cover producer-to-broker publication; consumer acknowledgements cover a separate delivery boundary. Neither knows the other business result. With the selected manual-ack policy, the worker commits its result and processed-job marker in one SQLite transaction before acknowledging the local queue. The queue removes inflight state; it does not independently inspect the database commit. An early acknowledgement followed by failure before result storage leaves the selected queue unaware of pending work.

If commit succeeds but the consumer stops before its acknowledgement is observed, work may be redelivered. RabbitMQ manual acknowledgements requeue unacked deliveries on channel/connection closure; our injected event is only a deterministic local analogy. The idempotency check finds the existing job marker, adds no second business effect, and acknowledges the new delivery. The result and marker share one transaction; external emails, files, or API effects do not automatically join it.

A producer database update and queue publication are writes to separate owners too. An outbox can commit the business row and pending event in one database transaction, then publish through a relay. Failure between publication and a sent marker can still duplicate publication, so consumers need idempotency. Our fixture observes local SQLite commit/rollback and finite relay state, not real broker confirms, cross-service transactions, or universal exactly-once behavior.

Read every scenario without motion

Early ack

The job was received
The worker received job-note-1, but the business result has not committed. Delivery knowledge does not substitute for a result row.
Delivery / relay
Delivery received; ack pending
Business database
Business commit pending
Outcome contract
Final outcome pending
Acknowledgement precedes the business commit
Here the queue applies acknowledgement first. It can remove its outstanding state without checking the database result as part of that decision.
Delivery / relay
queueOutstanding=0
Business database
Business commit pending
Outcome contract
Queue empty; outcome unknown
The worker stopped before commit
The worker stops after acknowledgement and before the business commit. No database result is created, and the earlier queue acknowledgement is not treated as undone.
Delivery / relay
queueOutstanding=0
Business database
resultRows=0
Outcome contract
Worker stopped before commit
Read the result independently
The result owner shows resultRows=0. Read together with the empty queue, this does not support business completion.
Delivery / relay
queueOutstanding=0
Business database
resultRows=0
Outcome contract
completedBusiness=false
Do not promote queue completion to success
Acknowledgement ended this delivery’s queue lifecycle. Business completion needs evidence from a different owner; here completedBusiness=false.
Delivery / relay
queueOutstanding=0
Business database
resultRows=0
Outcome contract
completedBusiness=false
A correction must account for the result
In the normal branch, result and processed marker commit in one transaction before acknowledgement. Acceptance requires the same job’s business commit and acknowledgement order, not just an empty queue.
Delivery / relay
early ack recorded
Business database
resultRows=0
Outcome contract
Commit and ack verified separately

Relay gap

Note and event commit together
The producer commits noteVersion=2 and pendingRows=1 in the same database transaction. This does not yet establish publication.
Delivery / relay
Publish outcome pending
Business database
noteVersion=2 / pendingRows=1
Outcome contract
Database intent committed
The relay published
publishEventsBeforeSentMarker=1 records a publish. The database sent marker has not updated, so the two owners do not yet share completion knowledge.
Delivery / relay
publishEvents=1
Business database
sentMarked=false
Outcome contract
Publish exists; marker absent
A stop between publish and sent marking
The relay may stop after publish before writing sent state. sentMarked=false does not mean publication never happened.
Delivery / relay
publishEvents=1 / relay stopped
Business database
sentMarked=false
Outcome contract
Publication cannot be inferred from sent=false
What does the retry know?
The retry sees a pending database event. It may publish the same previously published job again; the outbox alone does not remove this ambiguity.
Delivery / relay
duplicatePublishPossible=true
Business database
sentMarked=false
Outcome contract
Preserve the same job identity
Publication count reached two
publishEventsAfterRetry=2. Two publication events do not establish two business effects; the consumer’s handling of the same job must be examined separately.
Delivery / relay
publishEventsAfterRetry=2
Business database
sameDatabaseTransaction=true
Outcome contract
Publish count != business effect count
Outbox and idempotency solve different problems
Outbox binds a business update and event intent to one commit. Consumer idempotency addresses repeated delivery of the same operation. External effects do not automatically join this SQLite transaction.
Delivery / relay
publishEventsAfterRetry=2
Business database
externalEffectsInSqlTransaction=false
Outcome contract
Consumer idempotency still required

ASSUMPTION · BOUNDARY · CONTROL

Queue state is not business state

The controlled ledger separates accepted jobs, delivered/inflight work, business commits, and acknowledgements. The early-ack case has an empty queue but resultRows0: empty transport state does not prove business completion. This is a harmless synthetic policy outcome, not intervention in a real broker. A counter or worker “done” message must identify its completion boundary.

In commit-before-ack, resultRows=1 can coexist with an inflight delivery. A worker stop creates an after-commit gap and a retry can process the same job again. Delivery count alone is not business-effect count. The artifact shows two deliveries and one result. Acknowledgement mode, channel lifecycle, and retention differ across systems; the local adapter is no universal queue-protocol guarantee.

Read the idempotency record scope

The selected jobId marker lives in the business database. Writing the marker and result in separate transactions creates another failure gap. This lesson writes both in one SQLite transaction and independently checks that rollback leaves neither. A unique marker covers the chosen job identity, not every operation purpose or external effect.

A pending outbox row may be unpublished, or publication may have happened while the relay sent-state update lagged. sent=false therefore does not prove that no consumer received work. The controlled relay case preserves duplicate possibility without executing SQS, Kafka, RabbitMQ, or distributed failure reproduction. Review follows where delivery knowledge and business knowledge become current.

Read every scenario without motion

Redelivery

Establish the job identity
The local queue adapter produces delivery counts; independent SQLite SELECTs produce result and processed-marker observations. Correlated by the same jobId, these fields are neither broker telemetry nor captured packets. job-note-1 is the application’s business job identity. It is distinct from a queue delivery identity; redelivery first requires correlation to the same job.
Delivery observation
jobId=job-note-1
Result and marker
Result not read yet
Evidence interpretation
Correlation pending
Read the committed marker
Normal processing committed the result and processed marker together. The marker represents an existing business result for this job, not merely a worker-start message.
Delivery observation
jobId=job-note-1
Result and marker
resultRows=1 / processedRows=1
Evidence interpretation
Committed result for this job
Two deliveries were observed
redelivery.deliveries=2 and sameJobId=true. Two deliveries do not establish two different business operations.
Delivery observation
deliveries=2 / sameJobId=true
Result and marker
resultRows=1 / processedRows=1
Evidence interpretation
The same operation returned
No second effect was created
businessEffects=1, processedMarkers=1 and duplicateResultInserted=false are read together. The consumer used the existing marker on the second delivery without inserting another result.
Delivery observation
deliveries=2 / sameJobId=true
Result and marker
businessEffects=1 / duplicateResultInserted=false
Evidence interpretation
Same-job duplicate suppressed
Acknowledgement outcome was observed separately
inflightAfterAck=0 is the queue’s final state. It is different evidence from a single database result; each owner is verified separately.
Delivery observation
inflightAfterAck=0
Result and marker
businessEffects=1 / processedMarkers=1
Evidence interpretation
Queue and database outcomes separate
Keep the verified scope
In this local example, two deliveries of the same job leave one business effect. This does not establish universal exactly-once behavior across brokers, parallel workers or external APIs.
Delivery observation
deliveries=2
Result and marker
businessEffects=1 / processedMarkers=1
Evidence interpretation
universalExactlyOnce=false

Rollback intent

Separate commit and rollback examples
The local queue adapter produces delivery counts; independent SQLite SELECTs produce result and processed-marker observations. Correlated by the same jobId, these fields are neither broker telemetry nor captured packets. The outbox record contains two transaction outcomes. Compare them to examine whether the note update and event intent share a transaction.
Delivery observation
Publication not examined
Result and marker
Commit / rollback branches
Evidence interpretation
Atomic intent claim pending
Two outcomes accompany commit
The commit branch has noteVersion=2 and pendingRows=1. The new revision and publication intent remain inside the same database boundary.
Delivery observation
Publication not examined
Result and marker
commit: noteVersion=2 / pendingRows=1
Evidence interpretation
sameDatabaseTransaction=true
Rollback leaves no event
The rollback branch has noteVersion=1 and pendingRows=0. The unsuccessful transaction leaves neither a new revision nor a committed pending event.
Delivery observation
Publication not examined
Result and marker
rollback: noteVersion=1 / pendingRows=0
Evidence interpretation
Database intent rollback observed
Which question does this evidence answer?
The comparison supports joint commit or rollback of business row and event intent. It does not show consumer completion or caller receipt.
Delivery observation
Consumer outcome unknown
Result and marker
sameDatabaseTransaction=true
Evidence interpretation
Intent atomicity != end-to-end completion
Relay crosses another owner boundary
The relay later publishes the pending event. A gap between publication and sent marking means the earlier transaction does not make the whole chain atomic.
Delivery observation
duplicatePublishPossible=true
Result and marker
sameDatabaseTransaction=true
Evidence interpretation
Consumer outcome unknown
Separate acceptance criteria by layer
Database intent, publication observation, the same job’s consumer result and acknowledgement are separate criteria. Success at one layer does not complete missing evidence at another.
Delivery observation
publish evidence required
Result and marker
intent atomicity observed
Evidence interpretation
Separate result and acknowledgement evidence required

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Make completion and retry policies explicit

The local queue adapter produces delivery counts; independent SQLite SELECTs produce result and processed-marker observations. Correlated by the same jobId, these fields are neither broker telemetry nor captured packets. Validate the known index-public-note kind and noteId=tea before invoking the selected service. Delivery stays inflight until business commit, then manual acknowledgement removes it from the chosen queue. Independent SELECTs compare the job identity with result and processed-marker rows. The worker does not execute message data as code and uses no network broker, credentials, or user content.

The injected stop after commit and before acknowledgement requeues the delivery. A second delivery has the same job ID; the committed marker prevents another result. Observe acknowledgement separately: local acknowledgement intent differs from broker receipt. Our local adapter commits the event at method return and draws no network packet. Real deployments need tests for their broker protocol and recovery behavior.

Outbox and bounded work are separate controls

The producer commits its note update and outbox event in the same transaction; rolled-back work produces no event. A relay transfers only committed pending rows to the finite local queue. Delayed sent markers after publication can still duplicate work. Outbox reduces the dual-write intent gap without removing consumer idempotency. The test uses only own SQLite tables and a deterministic relay; external effects need another coordination scope.

Capacity, retry counts and failed-job handling are product policy. Define which errors permit retry, how many attempts are allowed and which final state reaches the caller. An acknowledgement does not replace a transaction, and queue durability does not prove business-result durability. Admission, delivery, commit and notification remain separate outcomes for the same job.

NOW APPLY IT TO THE CASE

Which owner completes publish, delivery, business commit and acknowledgement?

Atlas prepares job-note-1 to index the public tea note. The queue may no longer count it as outstanding while the independent result store still has no row. Delivery and business outcome are tracked separately.

Read accepted, delivery and committed-effect records at their respective owners. Do not rename unknown caller outcome as business rollback.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Public note job/delivery/outbox ledger

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "job": {
    "jobId": "job-note-1",
    "kind": "index-public-note",
    "noteId": "tea",
    "dataIsCode": false
  },
  "normal": {
    "pendingAfterPublish": 1,
    "inflightAfterDelivery": 1,
    "resultRowsAfterCommit": 1,
    "processedRowsAfterCommit": 1,
    "pendingAfterAck": 0,
    "inflightAfterAck": 0,
    "publisherConfirmIsBusinessResult": false
  },
  "redelivery": {
    "deliveries": 2,
    "businessEffects": 1,
    "processedMarkers": 1,
    "sameJobId": true,
    "duplicateResultInserted": false,
    "inflightAfterAck": 0
  },
  "earlyAck": {
    "queueOutstanding": 0,
    "resultRows": 0,
    "completedBusiness": false,
    "failure": "injected stop after ack before business commit"
  },
  "outbox": {
    "commit": {
      "noteVersion": 2,
      "pendingRows": 1
    },
    "rollback": {
      "noteVersion": 1,
      "pendingRows": 0
    },
    "relay": {
      "publishEventsBeforeSentMarker": 1,
      "sentMarked": false,
      "duplicatePublishPossible": true,
      "publishEventsAfterRetry": 2
    },
    "sameDatabaseTransaction": true
  },
  "limits": {
    "brokerExecuted": false,
    "simulation": "own finite Python queue adapter + sqlite3 business/outbox state",
    "externalEffectsInSqlTransaction": false,
    "universalExactlyOnce": false
  },
  "selector": {
    "language": "XPath",
    "xml": "<audit><job queueAcked=\"true\" businessCommitted=\"true\"/></audit>",
    "xpath": "count(/audit/job[@queueAcked='true' and @businessCommitted='false'])",
    "expected": 0,
    "positiveFixtureXml": "<audit><job queueAcked=\"true\" businessCommitted=\"false\"/></audit>",
    "positiveExpected": 1,
    "scope": "Only authored protocol-decision observations, not product log field names or a live HTTP capture.",
    "missingFieldBehavior": "Missing observation is insufficient evidence; zero matches is not proof of correct runtime behavior."
  }
}

job: Known public-note job schema, inert data.
normal/redelivery/earlyAck: Business results versus delivery/ack outcomes.
outbox: Same-database intent commit and finite relay gap.
selector: Synthetic early-acknowledgement boundary.

Own queue simulation and local SQLite only, not RabbitMQ/Kafka/SQS, parallel workers, or universal exactly-once testing.

Two reality checks

Queue acknowledgement or publisher confirm proves business commit.

These have separate delivery/publication scopes; the business-result owner needs independent verification.

An outbox removes duplicates and the need for idempotency.

The publish/sent gap can still duplicate work; the selected consumer keeps its effect idempotent within its transaction boundary.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

The queue acknowledged early, but resultRows is 0. Is the job business-complete?

Yes; a queue ACK commits every external/internal effect.
No; queue outstanding is 0 and completedBusiness=false.

Read the explained answer

No; queue outstanding is 0 and completedBusiness=false. — An ACK ends the outstanding delivery; stopping before business commit produces no selected result.

Why can deliveries 2 coexist with businessEffects=1?

Selected lesson artifact fields; teaching example

redelivery: {"deliveries":2,"businessEffects":1,"processedMarkers":1,"sameJobId":true,"duplicateResultInserted":false,"inflightAfterAck":0}

Selected duplicate detection prevents a second effect for the same job.
Two deliveries must mean two effects; the fixture is inconsistent.

Read the explained answer

Selected duplicate detection prevents a second effect for the same job. — SameJobId true and processedMarkers=1 define business-idempotency scope; they are not transport exactly-once.

An outbox relay published but did not write its sent marker. Why may retry duplicate publication, and what does the outbox keep atomic?

Read the explained answer

The selected database transaction commits/rolls back note version and pending outbox row together. Relay publication and sent-marker writing are stages outside that local unit; their gap may produce duplicate publication on retry. Consumer idempotency remains necessary; externalEffectsInSqlTransaction=false and brokerExecuted=false bound the evidence.

□ I separated outbox-local atomicity from end-to-end exactly-once.

□ I explained the publish/marker gap.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

RabbitMQ — Work Queues tutorialWhat This Tutorial Focuses On · Message acknowledgment · Fair dispatch
RabbitMQ 4.3 — Consumer acknowledgements and publisher confirmsAre Publisher Confirms Related to Consumer Delivery Acknowledgements? · Consumer Acknowledgement Modes and Data Safety Considerations · When Consumers Fail or Lose Connection: Automatic Requeueing
RabbitMQ 4.3 — ConsumersTerminology · Consumer Lifecycle · Acknowledgement Modes · Limiting Simultaneous Deliveries with Prefetch
AWS Prescriptive Guidance — Transactional outboxIntent · Motivation · Issues and considerations · Using an outbox table
SQLite — Transaction2. Transactions · 2.1. Read transactions versus write transactions · 2.2. DEFERRED, IMMEDIATE, and EXCLUSIVE transactions · 2.3. Implicit versus explicit transactions
Python 3.14 — sqlite3Tutorial · sqlite3.connect · Cursor.execute · How to use placeholders to bind values in SQL queries · Transaction control via the isolation_level attribute · How to use the connection context manager

YOUR NOTES / THIS BROWSER

Queues, producers, consumers, and workers

1. Core · Mechanism

Commit then ack

Commit/ack gap

Early ack stop

Outbox relay gap

When and for whom does a queue retain work?

Which boundaries do acknowledgements and commits cross?

2. Red · Trust & Impact

Early ack

Relay gap

Queue state is not business state

Read the idempotency record scope

3. Blue · Secure development & defense

Redelivery

Rollback intent

Make completion and retry policies explicit

Outbox and bounded work are separate controls

Which owner completes publish, delivery, business commit and acknowledgement?

Two reality checks

The queue acknowledged early, but resultRows is 0. Is the job business-complete?

Why can deliveries 2 coexist with businessEffects=1?

An outbox relay published but did not write its sent marker. Why may retry duplicate publication, and what does the outbox keep atomic?

Sources and scope