Pricing & Billing — standalone architecture

📖 Flow story — what really happens

Every cross-flow arrow is the same async handoff — no flow calls another directly. 1. The sending flow commits its data row plus an outbox row in one transaction. 2. A relay publishes the event to the event bus (Pub/Sub on GCP · EventBridge→SQS on AWS). 3. The bus's push-subscription POSTs it to the receiving flow's Cloud Run API, which processes it idempotently (duplicates ignored, deduped on event_id). Synchronous reads (e.g. getProductVersion) are plain request/response.

1. Underwriting's accept does NOT call Pricing. It commits two rows in one transaction: a uw_decision row (append-only) and an outbox row carrying DecisionMade(accept).
2. The outbox relay publishes DecisionMade to the event bus; Pricing's subscription delivers it by POSTing to the Pricing API (Cloud Run) — async, deduped on event_id so a redelivery can't double-rate.
3. Pricing rates the risk: base premium off Coverage A, adjusted by cat-model surcharges, mitigation credits (discounts for risk-reduction work like a fire-rated roof or cleared vegetation), taxes & fees (rate tables warehoused in BigQuery); it writes a quote row with the exact factors used.
4. On bind the premium is frozen — written once to an append-only premium ledger (write-once); later endorsements/refunds append deltas (change records), never edit the original.
5. That bind commits its own outbox row, so MarkedAsSold {policy_id, premium snapshot} publishes exactly once, atomically (as one all-or-nothing operation) with the commit; BillingInvoiceRequested goes to billing.
6. Servicing's install gate is the next subscriber on MarkedAsSold — the sold case moves on without Pricing ever waiting.