Data queues & asynchronous work

A *DTAQ allows programs or jobs to send and receive entries for interprocess communication. It can decouple a producer from a consumer and support FIFO, LIFO, or keyed organization as configured.

A queue transports work information; it does not by itself define a business workflow. Specify the payload format, sender/receiver behavior, waiting policy, and failure recovery. A queue name alone is not a guarantee of durable end-to-end processing.

QSNDDTAQ sends an entry and QRCVDTAQ receives one using the relevant API parameters. Correct queue/library naming, data length, payload storage, and optional keyed behavior matter. Receiving can wait according to the requested wait parameter.

Prototype the APIs accurately and follow their documented parameter types. Include a payload version and correlation identifier so both ends can evolve without silently interpreting different byte layouts. Test empty queues, timeouts, invalid lengths, and malformed entries.

FIFO favors arrival order; LIFO favors the most recently added entry; keyed queues support selection using a key and the specified comparison behavior. The choice should match how consumers identify and prioritize work.

Arrival order alone does not prove business ordering across multiple producers or concurrent consumers. If two updates to the same order must be serialized, define a per-order sequencing policy. Avoid claiming exactly-once execution merely because a queue is FIFO.

If the receive removes the entry, a crash before successful business processing can leave the transport entry gone while the work remains incomplete. Conversely, retry logic can repeat a business effect if it cannot tell whether the earlier attempt committed.

Persist business intent and status separately, and use idempotent processing with reconciliation. A robust design can send a durable work-record key on the queue, allowing unfinished work to be rediscovered. Treat the queue as a notification path, not the only evidence of business obligation.

Do not assume ordinary queue sends and receives are atomic participants in the database transaction. Journaling a queue and rolling back database changes are different capabilities.

For database-plus-message consistency, write durable outbound intent in the same database transaction as the business change, then let a dispatcher send and retry. A consumer uses an operation key to handle duplicates. This outbox approach addresses the gap between committing data and notifying another component.

Measure arrival and consumption rates, oldest work age, active consumers, receive waits, and processing duration. Separate a stopped consumer from a slow database, repeated poison entry, or saturated external service.

Use bounded retries and a defined quarantine/dead-letter process in the application design. Preserve the original work key and failure context. Increasing consumers may help independent work but can worsen contention when every entry updates the same hot record.