How would you set unit-of-work and connection-lifetime policy for a service mixing short requests, long batch jobs and multi-step flows?

## Start from one invariant Every workable policy reduces to a single sentence that a reviewer can apply without knowing the domain: > **A unit of work is open only while it is issuing statements.** Everything else is a consequence. A connection slot is a service-wide allocation; concurrency is slots divided by average hold time. Any span during which a boundary is open but not querying is capacity spent on nothing, and the four classic offenders are the same everywhere: a call to another system inside the boundary, waiting on a lock, rendering a response, and waiting for a human. ## Policy per workload class **Short request handlers.** A thin transactional boundary around the statements, with validation, authorisation checks against other systems, and response formatting outside it. Everything the response needs is loaded before the boundary ends, so nothing downstream can fetch. This is also where the default acquisition policy matters least, because the boundary contains little but statements. **Batch and background jobs.** The tempting shape — one unit of work for the whole run — fails on three axes at once: memory grows with everything ever loaded, one connection is held for hours, and a failure at 90% loses everything. The workable shape is chunked: 1. Read a bounded slice of work, ordered so slices are stable and resumable. 2. Open one unit of work and one transaction for that slice; process and commit it. 3. Discard the tracked set so the next slice starts empty, and let the connection go back to the pool between slices. 4. Record a checkpoint with the commit, so a re-run resumes at the boundary of the last committed slice. 5. Size the slice so a chunk's transaction is short; then a retry is cheap and a failure costs one slice. **Multi-step flows.** State survives across requests as detached objects held in the client or in a store with an expiry; each step opens its own short unit of work. Concurrency is enforced with a version column checked in the final update rather than by a transaction held open across the user's think-time. Abandoned flows expire on their own. **Streaming and export endpoints.** Treat them as batches with a socket attached. Either materialise before responding, or process in committed chunks; never hold one boundary open for the consumer's read speed. ## The budget, stated in numbers | Workload | Unit of work | Connection held for | Bounded by | |---|---|---|---| | Request handler | One per request | The statement phase | A latency budget per endpoint | | Batch job | One per chunk | One chunk | A maximum chunk duration | | Multi-step flow | One per step | One step | Nothing held between steps | | Streamed export | One per chunk | One chunk | Never the client's read speed | A concrete way to express the budget: publish a **maximum open time** per class — for example, request boundaries in the low tens of milliseconds, chunk transactions in the low seconds — and treat a breach as a defect rather than as tuning. Note the deliberate omission: none of this is about how many slots the pool has. Sizing is a separate decision, and a policy that only works at a particular pool size is not a policy. ## Making it hold - **Measure hold time, not query time.** The gap between them is the waste, and it is invisible on a query-latency dashboard. - **Alert on time spent waiting to borrow.** Rising borrow wait with an unremarkable server is the signature of scope problems; it fires long before user-visible timeouts. - **Attribute statements to code paths** and assert their counts in tests for the busiest paths, so a new per-row loop fails a build. - **Make "no calls to other systems inside the boundary" a review rule**, because it is checkable by reading a diff and it is where the worst holds come from. - **Cap what a single unit of work may accumulate** in a long-running process, so an unbounded loop fails loudly instead of degrading. ## The tradeoffs a lead actually owns The policy costs something and the honest version says so. Chunked batches give up whole-job atomicity, which means every job must be re-runnable and every chunk idempotent — real design work pushed onto job authors. Detached multi-step flows give up the guarantee that the data has not moved, replacing it with a version check and a conflict the user must resolve on the last screen. Loading everything at the boundary means read paths must state what they need, so a screen change becomes a change in two places. These are worth paying because the alternative — long-held scopes — fails as a *system* property: it degrades every workload at once, at peak, and it is diagnosed last, after the team has looked at the database, the queries and the pool size.