Worker-Oriented Platform
Anything that 'eventually happens' — recommendation rebuilds, reservation expiry, settlement generation, grace periods, analytics rollups — belongs in a worker, not a request path. Durable, retryable, recoverable workers make eventual work first-class, so the platform degrades and recovers gracefully instead of doing slow work inline.
Problem
Platforms accumulate work that "eventually happens": recommendation rebuilds, reservation expiry, settlement generation, grace periods, analytics rollups, and notification promotion. If that work lives inside request paths, users wait on slow operations and recovery becomes improvised.
Context
Use this pattern when the product has background obligations, delayed state transitions, rebuildable derived data, scheduled work, retries, rollups, notifications, expirations, or external side effects that do not need to complete inside the user's synchronous action.
Forces
- Request paths should stay predictable and bounded.
- Eventually consistent work still needs ownership, retries, observability, and operations.
- Delayed work can silently fail if it is treated as incidental code.
- Recovery is easier when work units can be re-run independently.
- Workers can become hidden second systems unless their inputs and effects are explicit.
Solution
Make eventual work first-class worker work. Give each worker a named responsibility, durable input, retry behavior, idempotence boundary, and operational entry point. Workers should be independently runnable for testing and operations, and their effects should remain tied to the relevant truth or projection homes.
Consequences
Request paths stay smaller. Slow or delayed work becomes observable and recoverable. The platform can degrade by pausing, retrying, or rebuilding worker outputs instead of blocking users or losing state. Operations become part of the platform design rather than a collection of scripts.
Failure Modes
- A request path performs slow rollups, rebuilds, or external side effects inline.
- A worker cannot be safely re-run.
- Retry behavior duplicates money, notifications, reservations, or relationship changes.
- Worker inputs are implicit queries instead of durable work records.
- Operators cannot run one worker for one scope during recovery.
Proof Points
settlement generation, membership grace periods, analytics rollups, and notification promotion are platform obligations that belong in durable workers.
- Ampriot — recommendation rebuilds, reservation expiry,
Full source pattern: 08-worker-oriented-platform.md.