Zen Algorithms · Insurance Lab← All flows
Flow 2 · Internal · Product

Product Design — standalone architecture

If you were asked to build just this flow: business analysts & actuaries author products (line → form → provisions → options) and the rules, versioned by effective date. It is write-rarely, read-constantly (every quote reads a product version). Every other flow is a black box here — they only ask "give me the product version effective on date D" and receive an immutable document (how product versioning works — worked example). Advance the maturity stage to see it grow.

Start: Vercel + Cloud Run + Cloud SQL — grow by stage (click any box for its definition)
Product flow grown across maturity stages: authors use a Vercel UI to a Cloud Run API over a bitemporal Cloud SQL store, publishing immutable version docs that downstream flows read, scaling to read replicas/CDN then AlloyDB. BA / Actuary internal, SSO Vercel UI authoring screens ? Cloud Run Product Authoring API ? Cloud SQL product_version (bitemporal) provision tree + rules ? emits → ProductVersionPublished {version id, line/form, effective date} ? Underwriting (reads versions) Pricing (reads versions) published doc → CDN ? read replica ? AlloyDB (HTAP) — heavy version fanout Profile B (non-breaking move) ?
active at this stage arrives in a later stage other flow (black box)

📖 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). The getProductVersion read below is a plain synchronous request/response, NOT an event.

  1. A business analyst/actuary authors a product as data in the authoring API (Cloud Run): line → form → provisions → options + compliance/risk rules.
  2. Publishing opens one transaction and inserts a new immutable product_version row (effective-dated; never an in-place edit) plus an outbox row holding ProductVersionPublished, then commits.
  3. The relay publishes ProductVersionPublished {version id, line/form, effective date} to the bus; Underwriting and Pricing consume it to warm their caches.
  4. Reads are separate and synchronous: getProductVersion(line, form, asOfDate) returns the immutable doc, served from a CDN + read replica so the hot read never touches the authoring primary. (Worked example: how a version is resolved.)
  5. At bind, Pricing stamps the chosen product_version id onto the policy, so you can reproduce exactly what was shown and sold.
  6. A new filing = a new product_version row; in-force policies keep their stamped version until renewal rolls them onto the current one.

Interfaces (the black-box contract)

DirectionContractWho
EmitsProductVersionPublished {version id, line/form, effective date}Underwriting, Pricing (warm caches)
Read APIgetProductVersion(line, form, asOfDate) → immutable docCustomer, Underwriting, Pricing
Consumes— (this flow is upstream of everything)

No other flow touches this database. They see only the published versions + the read API — so Product can be built, deployed, and scaled on its own.

← All flowsSee the full architecture →