Production engineering
Reveal answer and reasoning
Design a dispatcher around bounded claims, explicit claim identity, finite time and attempt budgets, and durable acknowledgment conditions. Decide how ordering, poisoning and retention interact with reclaiming work, rather than treating every pending row as interchangeable. Record which clock and storage owner decide expiry. Preserve stale-generation tests alongside successful claims, because a happy-path sent marker cannot establish ownership correctness. The portable comparison explains a known replacement, and actual SQLite checks establish this fixture's persisted lease behavior.
A production broker or shared database adds independent failure and consistency contracts that this local experiment does not provision.
Consider a worker that pauses long enough to lose its lease and then resumes. Its external request may still complete, so fencing the local sent update is not sufficient to guarantee a single remote effect. Use stable event identity and an appropriate consumer protocol, and decide which stale actor actions can still be tolerated. Keep network operations outside a long-held database transaction.
Test expired claims, reused owner names, wrong generations and uncertain delivery separately, with bounded retry behavior instead of extending a lease indefinitely whenever a system becomes slow.
What a strong answer covers
- The model prints ownedTrue, expiredTrue, stale ackFalse and current ackTrue.
- Actual acknowledgments also check persisted status, generation and expiry.
- A reclaimed lease implies possible duplicate delivery, not an exactly-once effect.
Common pitfall
Treating a reusable owner name or a lease expiry as proof of current ownership and non-delivery.
Follow-up questions
- What happens when the same worker name is reused for a newer claim?
- How would an already completed remote delivery be reconciled after local lease loss?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.