chartletv0.21.0chartlet.casoon.de

← All examples

Order platform and its data stores

Three services, each with its own database. Left to itself, every database follows its service, so they land at three depths and the Data tier boundary around them stretches over the queue and the worker. "sameRank": [["catalogDb", "ordersDb", "billingDb"]] puts the three at one position along the flow: the frame is one layer deep and the main path stays straight. A layout hint, not an edge; laid out again for the phone, where the tier is a row at the bottom. Illustrative values.

Order platform and its data stores

examples/data-tier.json
{
  "schemaVersion": 1,
  "type": "architecture",
  "title": "Order platform and its data stores",
  "source": "Illustrative reference architecture",
  "width": 1520,
  "height": 560,
  "architecture": {
    "boundaries": [
      {
        "id": "platform",
        "label": "Order platform"
      },
      {
        "id": "data",
        "label": "Data tier",
        "in": "platform"
      }
    ],
    "components": [
      {
        "id": "shopper",
        "label": "Shopper",
        "kind": "person"
      },
      {
        "id": "app",
        "label": "Shop app",
        "kind": "frontend"
      },
      {
        "id": "gateway",
        "label": "API gateway",
        "in": "platform"
      },
      {
        "id": "catalog",
        "label": "Catalog service",
        "in": "platform"
      },
      {
        "id": "orders",
        "label": "Order service",
        "in": "platform"
      },
      {
        "id": "queue",
        "label": "Order events",
        "kind": "queue",
        "in": "platform"
      },
      {
        "id": "billing",
        "label": "Billing worker",
        "in": "platform"
      },
      {
        "id": "catalogDb",
        "label": "Catalog",
        "sublabel": "Postgres",
        "kind": "database",
        "in": "data"
      },
      {
        "id": "ordersDb",
        "label": "Orders",
        "sublabel": "Postgres",
        "kind": "database",
        "in": "data"
      },
      {
        "id": "billingDb",
        "label": "Invoices",
        "sublabel": "Postgres",
        "kind": "database",
        "in": "data"
      }
    ],
    "connections": [
      {
        "from": "shopper",
        "to": "app",
        "label": "orders"
      },
      {
        "from": "app",
        "to": "gateway",
        "technology": "HTTPS"
      },
      {
        "from": "gateway",
        "to": "catalog",
        "label": "browse"
      },
      {
        "from": "gateway",
        "to": "orders",
        "label": "checkout"
      },
      {
        "from": "catalog",
        "to": "catalogDb",
        "technology": "SQL"
      },
      {
        "from": "orders",
        "to": "ordersDb",
        "technology": "SQL"
      },
      {
        "from": "orders",
        "to": "queue",
        "label": "publishes"
      },
      {
        "from": "queue",
        "to": "billing",
        "label": "delivers"
      },
      {
        "from": "billing",
        "to": "billingDb",
        "technology": "SQL"
      }
    ],
    "mainPath": [
      "shopper",
      "app",
      "gateway",
      "orders",
      "queue",
      "billing"
    ],
    "sameRank": [
      [
        "catalogDb",
        "ordersDb",
        "billingDb"
      ]
    ]
  },
  "mobile": {
    "width": 440,
    "height": 1100
  }
}
Focus
Order platform and its data stores
Order platform and its data storesArchitecture diagram with 10 components and 9 connections in 2 boundaries. Order platform: API gateway, Catalog service, Order service, Order events, Billing worker, Data tier. Data tier (in Order platform): Catalog, Orders, Invoices. Main path: Shopper → Shop app → API gateway → Order service → Order events → Billing worker. Most connected: API gateway and Order service (3 connections each). Nothing leads into Shopper. Nothing leads out of Catalog, Orders and Invoices. Shopper (person): connects to Shop app (orders). Shop app (frontend): connects to API gateway (via HTTPS). API gateway (service): connects to Catalog service (browse) and Order service (checkout). Catalog service (service): connects to Catalog (via SQL). Order service (service): connects to Orders (via SQL) and Order events (publishes). Order events (queue): connects to Billing worker (delivers). Billing worker (service): connects to Invoices (via SQL). Catalog (database): no outgoing connection. Invoices (database): no outgoing connection. Orders (database): no outgoing connection.Order platformData tierShopper → Shop app: ordersShop app → API gateway: [HTTPS]API gateway → Catalog service: browseAPI gateway → Order service: checkoutCatalog service → Catalog: [SQL]Order service → Orders: [SQL]Order service → Order events: publishesOrder events → Billing worker: deliversBilling worker → Invoices: [SQL]orders[HTTPS]browsecheckout[SQL][SQL]publishesdelivers[SQL]ShopperShopperShop appShop appAPI gatewayAPI gatewayCatalog serviceCatalog serviceOrder serviceOrder serviceOrder eventsOrder eventsBilling workerBilling workerCatalog – PostgresCatalogPostgresOrders – PostgresOrdersPostgresInvoices – PostgresInvoicesPostgres
Order platform and its data storesArchitecture diagram with 10 components and 9 connections in 2 boundaries. Order platform: API gateway, Catalog service, Order service, Order events, Billing worker, Data tier. Data tier (in Order platform): Catalog, Orders, Invoices. Main path: Shopper → Shop app → API gateway → Order service → Order events → Billing worker. Most connected: API gateway and Order service (3 connections each). Nothing leads into Shopper. Nothing leads out of Catalog, Orders and Invoices. Shopper (person): connects to Shop app (orders). Shop app (frontend): connects to API gateway (via HTTPS). API gateway (service): connects to Catalog service (browse) and Order service (checkout). Catalog service (service): connects to Catalog (via SQL). Order service (service): connects to Orders (via SQL) and Order events (publishes). Order events (queue): connects to Billing worker (delivers). Billing worker (service): connects to Invoices (via SQL). Catalog (database): no outgoing connection. Invoices (database): no outgoing connection. Orders (database): no outgoing connection.Order platformData tierShopper → Shop app: ordersShop app → API gateway: [HTTPS]API gateway → Catalog service: browseAPI gateway → Order service: checkoutCatalog service → Catalog: [SQL]Order service → Orders: [SQL]Order service → Order events: publishesOrder events → Billing worker: deliversBilling worker → Invoices: [SQL]orders[HTTPS]browsecheckout[SQL][SQL]publishesdelivers[SQL]ShopperShopperShop appShop appAPI gatewayAPI gatewayCatalog serviceCatalogserviceOrder serviceOrder serviceOrder eventsOrder eventsBilling workerBilling workerCatalog – PostgresCatalogPostgresOrders – PostgresOrdersPostgresInvoices – PostgresInvoicesPostgres

Source: Illustrative reference architecture

Show chart data
Data for Order platform and its data stores
ComponentKindBoundaryConnects to
ShopperpersonShop app (orders)
Shop appfrontendAPI gateway (via HTTPS)
API gatewayserviceOrder platformCatalog service (browse), Order service (checkout)
Catalog serviceserviceOrder platformCatalog (via SQL)
Order serviceserviceOrder platformOrders (via SQL), Order events (publishes)
Order eventsqueueOrder platformBilling worker (delivers)
Billing workerserviceOrder platformInvoices (via SQL)
CatalogdatabaseOrder platform › Data tier
InvoicesdatabaseOrder platform › Data tier
OrdersdatabaseOrder platform › Data tier
  • Architecture diagram with a shared rank (phone variant)
  • Line up what belongs to one tier