TableAreaAccess TypeData / EffectCoupling
subs_accountA1, A3direct DBAccount flags, billing profile. A1 writes profiles, A3 writes bad_debt.Data coupling
subs_customerA1, A2direct DBStripe ↔ CF customer mapping. A1 writes during setup, A2 during checkout.Data coupling
subs_dunningA1 (read), A3direct DBDunning state per account. A3 writes, A1 reads for account status.Data coupling
subs_mandateA2 (read), A3direct DBPayment mandates. A3 reads and writes, A2 checks before operations.Data coupling
subs_stuck_eventsA3direct DBUnprocessed webhook events. A3 writes, ops reads for investigation.Data coupling
StripeAll areaswebhook → DBPayment status, mandates, invoice state. External source of truth.External

Account state is scattered across six stores. Three areas mutate overlapping subsets. No single component reads all six — the recompute engine is the first to attempt a unified view by reading all five subs-api tables.

areas stores external read/write write profiles write setup read write checkout write invoices write bad_debt read/write write charges webhooks A1: Accounts A2: Commerce A3: Billing cf_prod accounts, entitlements billing_prod invoices, charges subs_account flags, profiles subs_customer Stripe mapping subs_dunning dunning state Stripe external
Six stores, three areas, and their access patterns. Overlapping writes create consistency risk.
Gather All State Compute Correct Apply Diff Emit Events

The target architecture centralizes state resolution. One component gathers all signals, computes what the account state should be, applies the minimal diff, and emits domain events. The recompute engine is the first implementation of this pattern — it reads all five subs-api tables and determines the correct dunning state in a single pass. Disagreement is structurally impossible when one reader sees everything.