Standardizing async workflows without taking ownership away from teams.

Repeated workflow decisions create delivery and operational risk.

The decision has to protect autonomy and consistency at the same time.

• Team autonomy

  Teams still need to own service behavior, deployment timing, data contracts, and domain-specific failure choices.

• Service variability

  Workflows can share an intake-state-async-notification shape, but they still differ in payloads, authorization, deadlines, and downstream systems.

• Operational consistency

  Retry limits, dead-letter handling, state retention, alarms, and dashboards should not depend on which team implemented the pattern last.

• Migration cost

  The path has to work for new services first and let existing services adopt only where the return is worth the change.

• Support model

  The shared layer needs clear ownership for defaults, bugs, versioning, and support boundaries.

• Reversibility

  A team should be able to stop using the pattern without turning it into a major platform extraction project.

Five criteria kept the decision grounded.

The criteria are intentionally practical. They test whether the choice helps teams ship, operate, and change direction, not only whether it looks clean on an architecture diagram.

Three shapes of platform ownership.

1. 01

   Service-specific implementations

   Where it fits. Fits when a workflow is unusual, low-volume, or tightly coupled to one service's domain model.

   Primary risk. Every team re-decides state shape, queue policy, retries, alerts, and support handoff. Delivery looks autonomous, but platform learning does not compound.

2. 02 Recommended

   Reusable construct library

   Where it fits. Fits when teams need local ownership, but the organization needs consistent workflow defaults and a shared vocabulary.

   Primary risk. Requires disciplined versioning, examples, and support ownership. Without that operating model, the library becomes another dependency teams work around.

3. 03

   Central platform service

   Where it fits. Fits when the workflow becomes a high-scale product capability with uniform contracts, centralized operations, and strong governance needs.

   Primary risk. Can over-centralize too early. Teams wait on platform capacity, special cases pile up, and local product behavior becomes harder to change.

Choose a reusable construct library, but treat it as an operating model.

The same recommendation needs different wording for each audience.

1. 01

   Engineering detail

   Use a construct library to standardize the workflow skeleton: intake boundary, durable state, async queueing, retry and dead-letter defaults, lifecycle hooks, and baseline observability. Services keep their own handlers, payload schemas, authorization, and domain transitions.

2. 02

   Delivery and business impact

   The decision removes repeated platform design from each team's backlog while keeping teams able to ship service-specific behavior. It reduces inconsistent operational defaults without creating a central service dependency for every workflow change.

3. 03

   Team adoption guidance

   Adopt the construct for new workflows that match the common shape. Opt out when the workflow needs unusual ordering, latency guarantees, regional topology, or a different state model. Raise gaps as versioned library changes, not one-off copies.

Adoption succeeds only if the pattern is easy to use and easy to question.

1. 01

   Publish a short decision note with the problem, selected option, non-goals, and opt-out rules.

2. 02

   Provide a reference implementation that creates the intake route, state store, queue, worker, notification hook, and alarms.

3. 03

   Create a design checklist for retry policy, state retention, notification consumers, dashboard needs, and runbook ownership.

4. 04

   Version defaults deliberately, with migration notes for breaking changes and a support window for older versions.

5. 05

   Keep an escape hatch for teams that need raw infrastructure composition or a different workflow topology.

6. 06

   Name adoption risks up front: documentation drift, unclear bug ownership, slow updates, and teams copying older examples.

The decision leaves room for opt-outs and later evolution.

Implementation details for the recommended pattern live in the CDK workflow case. That page covers the construct surface, generated AWS shape, IAM grant boundaries, and local synth validation. This page stays on the decision and adoption model.