Desk

API Delivery Desk

Borrowed from how internal platform teams ship: a single place to align architecture, trace data movement, and sign releases without improvising in chat threads.

Service architecture

Boundaries are drawn before frameworks: which processes own which tables, where synchronous calls are allowed, and how asynchronous workers drain queues. The desk insists on diagrams that match repository folders — mismatch blocks promotion to staging.

  • Domain ownership map per bounded context
  • Explicit public vs internal package lists
  • Failure domains annotated with blast-radius notes
Architectural sketch of services connected by arrows on paper.

Data flow diagram

Edge gateway Auth service Orders API Worker + queue Postgres

Arrows imply allowed producer/consumer pairs — bi-directional hacks require a desk exception logged in Git.

Release checklist

  1. Schema migrations applied to staging with rollback script attached.
  2. Feature flags default to safe paths; kill switches tested once per release train.
  3. Observability: new metrics/dashboards linked in the change ticket.
  4. Support macros updated if customer-visible behaviour shifts.
  5. Rollback owner named — not “the on-call person maybe”.

The desk is picky on purpose. Participants carry the checklist into Think Netcore deployment labs so muscle memory forms before production access.

Discuss a private desk session