Architectures ossify. What is your evolution thesis — what changes at 10x team size and 100x load, and what is designed to survive?

The full executive answer

The thesis is evolutionary architecture: keep the expensive-to-change decisions few and standard, make everything else cheap to change, and let measured pressure — not fashion — trigger each transition. The load-bearing decisions designed to survive: Postgres as the system of record with database-enforced tenant isolation; the typed event catalogue as the inter-module contract; the versioned public API envelope; and the cell model as the unit of both residency and scale. Those are the platform's constitution, and they are all industry-standard technologies.

What is explicitly expected to change: the packaging of compute. Today, 68 modules in one deployable, because one small team owns everything. The first extraction candidates are already visible because the event bus draws their boundaries — the AI generation workers (which already run as scheduled background jobs with their own timeout budgets) and webhook delivery (which already operates as an independent worker off the durable outbox). Extraction is triggered by Conway's-law pressure — when a second or third team needs independent deploy cadence — or by a measured scaling asymmetry, not by a rewrite ambition. Database evolution runs the same way: vertical first, read replicas next, new cells for residency and load, all before any exotic sharding.

And the honest anti-ossification control is the one we already live by: the five-gate CI pipeline and 3,577 tests are what make continuous structural refactoring affordable. Architectures ossify when change is risky; our whole delivery system is built to keep change cheap. In TOGAF terms, we run a lightweight architecture-decision discipline — decisions and their trade-offs recorded in the repository as working agreements — rather than a shelf of unread architecture documents.