Async processing
Doing work outside the request that triggered it, with a guarantee that it eventually happens — deferred jobs, retries, and periodic work. Distinct from messaging, which is about telling other systems.
LEFT OPEN ON PURPOSE
The core: The core ships an outbox that defers emitted events until the current transaction commits.
Where it stops: It stops before durable queues, retry policies, dead-lettering and periodic scheduling.
Coverage is editorial and dated (2026-08-31). It is not a verdict — a core answer can still be the wrong one for your stack.
CONSTRAINED BY
Running one deployment that serves many tenants, with tenant-isolated data and per-tenant onboarding. A foundation choice rather than a feature: it narrows the options in almost every capability downstream, most sharply in caching and anything holding state in process.
YOUR OPTIONS — 2
The default answer for asynchronous work in CAP Node. Survived a CAP major without a breaking change, releases on a predictable cadence, and the transactional guarantees are real rather than claimed.
Kafka adapter for CAP, exposing Kafka topics as a CDS messaging service.
No editorial call yet — signals only.
TASKS IN THIS CAPABILITY
Work triggered by a request must not run inside it — sending mail, calling a slow downstream, recalculating a projection. You need it to happen exactly once, survive a restart, and not fire on every replica at once.