Architecture delta · Diagram Design

Order fulfilment, before and after

Order fulfilment, before and after A durable order queue replaces the legacy dispatcher, Orders API changes from v1 to v2, the fulfilment worker moves without changing implementation, and the storefront and database stay unchanged, with seven component and relationship changes listed between both snapshots. Before Synchronous dispatch · v1 Changes Four components · three relationships After Queued fulfilment · v2 r1 · HTTPS r2 · REWIRED r3 · REMOVED r5 · SQL = storefront · UNCHANGED Storefront web:v1 ~ api · CHANGED Orders API /orders · v1 − legacy · REMOVED Legacy dispatcher dispatcher:v1 ↔ worker · MOVED Fulfilment worker fulfilment:v1 = db · UNCHANGED Orders database PostgreSQL Same worker, moves right → 01 CHANGED · apiOrders API v1 → v2 02 REMOVED · legacyRetire legacy dispatcher 03 ADDED · queueIntroduce durable order queue 04 MOVED · workerFulfilment worker: left → right 05 REWIRED · r2Orders API: dispatcher → queue 06 REMOVED · r3Dispatcher → worker 07 ADDED · r4Queue → worker PRESERVED Storefront · database · r1 · r5 r1 · HTTPS r2 · REWIRED r4 · ADDED r5 · SQL = storefront · UNCHANGED Storefront web:v1 ~ api · CHANGED Orders API /orders · v2 + queue · ADDED Order queue durable · at-least-once ↔ worker · MOVED Fulfilment worker fulfilment:v1 = db · UNCHANGED Orders database PostgreSQL Same worker, new placement. = Unchanged + Added − Removed ~ Changed ↔ Moved ⇢ Rewired IDs persist across snapshots. Dashed and dotted strokes encode change, not protocol. 6 components · 5 relationships · 7 changes

Scroll the diagram horizontally to compare both snapshots and the change ledger.