chartletv0.21.0chartlet.casoon.de

← All examples

Billing moves from the monolith to its own service

Billing moves out of a monolith. The old path is deprecated (dotted, gray), the new service and its connections are planned (dashed, violet), the gateway, the accounts database and the payment call are critical (strong red). Each role also carries a badge or a line pattern, so it reads without color; the legend names only the roles used, and the description and the table name every role. Illustrative values.

Billing moves from the monolith to its own service

examples/billing-migration.json
{
  "schemaVersion": 1,
  "type": "architecture",
  "title": "Billing moves from the monolith to its own service",
  "source": "Architecture review, migration plan",
  "width": 1400,
  "height": 420,
  "architecture": {
    "boundaries": [
      {
        "id": "platform",
        "label": "Platform"
      }
    ],
    "components": [
      {
        "id": "customer",
        "label": "Customer",
        "kind": "person"
      },
      {
        "id": "portal",
        "label": "Customer portal",
        "kind": "frontend"
      },
      {
        "id": "gateway",
        "label": "API gateway",
        "kind": "security",
        "in": "platform",
        "role": "critical"
      },
      {
        "id": "monolith",
        "label": "Monolith",
        "sublabel": "billing module",
        "in": "platform",
        "role": "deprecated"
      },
      {
        "id": "billing",
        "label": "Billing service",
        "in": "platform",
        "role": "planned"
      },
      {
        "id": "events",
        "label": "Invoice events",
        "kind": "queue",
        "in": "platform",
        "role": "planned"
      },
      {
        "id": "db",
        "label": "Accounts",
        "sublabel": "Postgres",
        "kind": "database",
        "in": "platform",
        "role": "critical"
      },
      {
        "id": "psp",
        "label": "Payment provider",
        "kind": "external"
      }
    ],
    "connections": [
      {
        "from": "customer",
        "to": "portal",
        "label": "pays"
      },
      {
        "from": "portal",
        "to": "gateway",
        "label": "calls",
        "technology": "HTTPS"
      },
      {
        "from": "gateway",
        "to": "monolith",
        "label": "routes today",
        "role": "deprecated"
      },
      {
        "from": "gateway",
        "to": "billing",
        "label": "routes after",
        "role": "planned"
      },
      {
        "from": "monolith",
        "to": "db",
        "technology": "SQL",
        "role": "deprecated"
      },
      {
        "from": "billing",
        "to": "db",
        "technology": "SQL",
        "role": "planned"
      },
      {
        "from": "billing",
        "to": "events",
        "label": "publishes",
        "role": "planned"
      },
      {
        "from": "billing",
        "to": "psp",
        "label": "charges",
        "technology": "HTTPS",
        "role": "critical"
      }
    ]
  }
}
Focus
Billing moves from the monolith to its own service
Billing moves from the monolith to its own serviceArchitecture diagram with 8 components and 8 connections in 1 boundary. Platform: API gateway, Monolith, Billing service, Invoice events, Accounts. Most connected: Billing service (4 connections). Nothing leads into Customer. Nothing leads out of Invoice events, Accounts and Payment provider. Bottleneck: API gateway; without it the diagram falls apart. Customer (person): connects to Customer portal (pays). Customer portal (frontend): connects to API gateway (calls, via HTTPS). API gateway (security): connects to Monolith (routes today) and Billing service (routes after). Monolith (service): connects to Accounts (via SQL). Billing service (service): connects to Accounts (via SQL), Invoice events (publishes) and Payment provider (charges, via HTTPS). Accounts (database): no outgoing connection. Invoice events (queue): no outgoing connection. Payment provider (external system): no outgoing connection. Roles: critical: API gateway, Accounts, Billing service → Payment provider; planned: Billing service, Invoice events, API gateway → Billing service, Billing service → Accounts, Billing service → Invoice events; deprecated: Monolith, API gateway → Monolith, Monolith → Accounts.PlatformCustomer → Customer portal: paysCustomer portal → API gateway: calls [HTTPS]API gateway → Monolith: routes todayAPI gateway → Billing service: routes afterMonolith → Accounts: [SQL]Billing service → Accounts: [SQL]Billing service → Invoice events: publishesBilling service → Payment provider: charges [HTTPS]payscalls[HTTPS]routes todayroutes after[SQL][SQL]publishescharges[HTTPS]CustomerCustomerCustomer portalCustomer portalAPI gatewayAPI gateway!Monolith – billing moduleMonolithbilling module−Billing serviceBilling service+Invoice eventsInvoice events+Accounts – PostgresAccountsPostgres!Payment providerPayment provider!Critical+Planned−Deprecated

Source: Architecture review, migration plan

Show chart data
Data for Billing moves from the monolith to its own service
ComponentKindBoundaryRoleConnects to
CustomerpersonCustomer portal (pays)
Customer portalfrontendAPI gateway (calls, via HTTPS)
API gatewaysecurityPlatformcriticalMonolith (routes today, deprecated), Billing service (routes after, planned)
MonolithservicePlatformdeprecatedAccounts (via SQL, deprecated)
Billing serviceservicePlatformplannedAccounts (via SQL, planned), Invoice events (publishes, planned), Payment provider (charges, via HTTPS, critical)
AccountsdatabasePlatformcritical
Invoice eventsqueuePlatformplanned
Payment providerexternal system
  • Architecture diagram with roles
  • Show what changes in a migration