Event-driven order architecture

// Separate reservation, payment and fulfilment boundaries; annotate compensating actions.
// Synthetic worked example: all entities, schedules and measurements are illustrative.
// Every string below is EXAMPLE text from a fictional model: replace it.
// Replace assumptions and inputs before applying this model to actual work.

system platform {
  title: "Illustrative Event-driven order architecture"
  owner: "Architecture working group"
}

actor user {
  title: "Buyer"
  kind: "user"
  depends: [s0]
}

service s0 {
  title: "Checkout API"
  runtime: "Browser or edge client"
  tier: "edge"
  depends: [d0]
}

service s1 {
  title: "Order orchestrator"
  runtime: "Stateless service"
  tier: "core"
  depends: [s0, s2, s3]
}

service s2 {
  title: "Inventory reservation"
  runtime: "Background worker"
  tier: "core"
  depends: [d0]
}

service s3 {
  title: "Payment adapter"
  runtime: "Durable worker"
  tier: "core"
  depends: [d1]
}

service s4 {
  title: "Fulfilment worker"
  runtime: "Application service"
  tier: "core"
  depends: [s1]
}

datastore d0 {
  title: "Order ledger"
  kind: "postgres"
}

datastore d1 {
  title: "Payment outcome log"
  kind: "object-store"
}

view architecture: c4_container(platform)