The thesis
Everything in v3 was built for the load of a handful of marketplace lawyers, and it shows in the configuration, not the code. Two reframes carry the whole audit.
TL;DR. The machinery to survive Woodstock mostly already exists and is switched off: autoscaling pinned to one task per service, an alerting pipeline built with zero consumers, a database pooler configured with no upper bound. Of 39 findings, all six critical database fixes are config-only. The real risk is the act of onboarding (mailbox backfill, the document import, the day-one login storm), not steady state, so the core mitigation is pacing, not raw capacity. Fixed infra to reach full Woodstock costs roughly +$1.0–1.7k/mo.
<10 → 82
lawyers on v3, today to full Woodstock (~8–12× active persons)
67%
of the 225-connection DB ceiling used at <10 lawyers, already swapping
6 / 6
critical shared-database fixes that are config-only
350–620
legal files silently lost on the import today, no error raised
+$1.0–1.7k/mo
fixed infra to be full-Woodstock ready (~the July right-sizing, given back)
2 → ~130
Woodstock mailboxes connected today vs fresh connects at S2
We designed against three checkpoints, one primary target. The bars rise with the load each stage puts on the shared platform.
Today
<10
lawyers · ~90 people/day
S1 · first wave
16 · 2–3×
+ ~40 back-office
S2 · full Woodstock
82 · 8–12×
the design target
S3 · 2027
+firms · 20–30×
pipeline + ABS · sensitivity
Switched off, not missing
All 31 production services run one task each, with autoscaling policies attached but pinned to a single instance. The saturation-alerting pipeline is built end to end and has zero consumers. The pooler that should protect the database is configured with no ceiling. The fixes are configuration, not a rewrite.
Transients, not steady state
At full Woodstock most systems cope in steady state. What breaks is the act of onboarding: the serialized mailbox backfill, the one-time document import, the matter-creation fan-out, the day-one login storm, all hitting one shared database at once. The mitigation is sequencing and pacing, which is cheap.
Where the risk actually sits
Read this as a heat map. Rows are severity, columns are when a finding starts to bite. The critical findings cluster in the two left columns, today and the first wave, and the coloured dot on each says how expensive the fix is. Almost all of the hottest cells are green.
Today
First wave
S1 · 16 lawyers
S1 · 16 lawyers
Full Woodstock
S2 · 82 lawyers
S2 · 82 lawyers
Critical
F6 db-prx single-task SPOF
F11 email OOM → 503 cascade
F31 Clerk total-auth SPOF
F1 DB connection exhaustion
F2 RDS single-AZ
F18 silent legal-file loss
F3 storage cap + WAL slot
High
F29 no saturation alerting
F14 contentretrieval 99.4% mem
F12 grace=0 deploy trap
F19 OpenSearch single-node
F25 deploys kill live streams
F9 email backfill 5–8 day queue
F13 no scale lever (desired=1)
F30b Inngest worker cap
F17 ingestion backfill lane unwired
F24 case-context engine fixed at 2
F8 email polling DB load
F20 ingestion mgmt hub fixed-3
config-only
small PR
structural
· 18 of 39 findings shown; full ledger in the deep-dive
The scariest finding is also the cheapest: one shared db.t4g.small, single-AZ, whose pooler is set to allow 1,600 backend connections against a 225 ceiling. It breaks inside the first wave, before 16 lawyers are fully on. The fix is a config change.
Shared database connections — the scariest finding (F1)
151 used today · 67%
225 ceiling
→ The pooler is configured with no cap: up to 1,600 backend connections can open against that 225 ceiling, so one onboarding burst in the first wave exhausts it fleet-wide. The pooler that should protect the database is configured not to. Fix: a pgbouncer config change.
The five things that break
1
The shared database, first
16 logical databases on one burstable instance, connection and memory bound. 8 to 12 times the people exhausts it long before CPU matters. Every fix here is config-only.
67%
of ceiling at <10 lawyers
2
Email onboarding, the named blocker
~130 fresh mailboxes through a backfill serialized one at a time, and a single-task email service a heavy mailbox can OOM into a 503. Two config changes bring the wave under a day.
5–8 days
→ under a day (config)
3
The import loses records silently
The dedicated import lane is unwired, and ~0.27% of documents hit a timeout and are permanently discarded with no error event, during the exact migration Woodstock is trusting us with.
350–620
files lost, no alert
4
The AI surface loses work on every deploy
Chat and voice streams are pinned to instance memory, so a deploy or scale-in kills every in-flight generation. The durable-streams fix is written but unmerged.
3–25
generations lost / deploy
5
Nothing tells us any of this is happening
No saturation alerting exists, yet the delivery pipeline is already built with zero consumers. The highest-leverage item in the whole audit.
~20 alarms
pipeline already built
The external limits are fine. Our configuration is the ceiling.
Reading the vendor billing pages turned three feared capacity risks into cost footnotes. OpenAI runs at 180M tokens per minute, not a wall even for a full LEAP migration. Anthropic is on a custom tier at 10M input tokens per minute, well above the busiest projection. Inngest bills run and step overage rather than hard-capping it.
The one vendor limit that genuinely binds is Inngest Connect workers. New infrastructure forces the 16 private-networked services onto always-connected workers, and we draw about 19 of a 50-worker cap today. Taking the fleet to two or three tasks each for HA reaches 32 to 48, which tips over 50 once a fleet-wide deploy overlaps. It is a soft, paid limit though, raised at ten dollars a worker or on an enterprise plan, so it does not block scaling. Usefully, it puts a real dollar figure on the consolidation case: every service the guild consolidates removes a paid worker.
What it costs to be ready
The fixed-infra number is small and expected. The real exposure is the variable LLM bill, which grows with chat volume and per-turn context size, a cost-engineering problem rather than an infrastructure one.
Fixed infra
delta to S2
delta to S2
LLM spend
today → S2
today → S2
Fixed infra is roughly the July right-sizing savings given back, plus the Inngest worker add-on. One-time document import in LLM terms is only $0.4–0.8k.
How to execute: gates, not a backlog
Each gate is a precondition for the scale it protects. The full trigger-to-action playbook, with metric thresholds, is in the deep-dive.
Gate 0 · any ramp
Alarm stack on the existing pipeline; pgbouncer caps, Multi-AZ, storage autoscaling; fix the grace=0 deploy trap; bump the near-OOM services; instrument the silent-discard path.
→
Gate 1 · first wave
DB instance bump; email backfill concurrency and a second instance; wire the ingestion backfill lane; raise the Inngest worker cap; stagger day-one logins and pre-create matters.
→
Gate 2 · full Woodstock
Non-burstable RDS; OpenSearch HA; durable streams; case-context autoscaling; Anthropic context truncation and caching.
→
Structural · 2027
US region strategy; event and outbox retention with framework 1.0; request-based autoscaling; Clerk fallback.
One hard rule of order: do not turn on request-based scale-out before the database and pool work lands. More tasks on today's pool config multiplies connection demand into a 225-connection instance. Always DB and pool, then memory and HA, then worker-split, then request-scaling.
The full LEAP migration is a separate, larger event
Jaime's LEAP-to-v3 migration is a different object from the open-case import above. On stated-assumption guidelines it is roughly 10 to 25 thousand matters and half a million to two million documents, four to ten times the open-case import. The real number hinges on the LEAP export count.
The cost stays immaterial, two to eight thousand dollars in LLM terms, and the vendor limits are not a wall. It is a throughput, records-integrity and orchestration problem, and it forces the one genuinely structural infrastructure build the rest of the audit could defer: OpenSearch onto a multi-node HA domain sized to the full corpus. Sequenced properly, with fan-out suppressed on import and a reconciliation harness so no legal record is silently lost, it is a two to nine week controlled operation. Run through the live paths at today's config, it is a multi-month queue with silent loss.
Where this lands on the roadmap
This fills a genuinely empty slot. The backend guild's board has framework 1.0 and a consolidation proposal, but nothing on load testing, autoscaling, database sizing, pooling, SLOs, rate limiting, or firm-ramp readiness. These findings should become guild work, not a parallel track. Framework 1.0 should carry the retention policy and the standard health-check grace default. Consolidation and the worker-split finding are the same question from two angles, and the audit now hands consolidation a hard dollar figure through the Inngest worker cost. The platform does not need to be rebuilt for Woodstock. It needs to be switched on and paced.
Read the deep-dive
The full strategy, demand model, 39-finding ledger and per-area detail live in Notion. v3 Capacity Strategy — Woodstock Ramp →
The evidence
Ten deep-dive artifacts, each adversarially verified, plus the load model, triggers playbook and LEAP sizing in the lawhive-capacity-audit repo. No headline conclusion was refuted under verification.