From 8,000 to 500,000 consultations a month without a rewrite

When we picked up the engagement the platform handled around 8,000 consultations a month on a single monolith with a managed database and a third-party video SDK. Eighteen months later it handled 500,000. The architecture that got there is recognisably the same system — which was a deliberate choice, and the right one.

What broke, in order

The failure sequence in a scaling system is remarkably consistent. Knowing the order is most of the value of having done it before.

• ~25k/month: database connection pool exhaustion under appointment-booking bursts
• ~60k/month: media session negotiation failures at regional edges
• ~120k/month: scheduling logic contention — double-booked clinicians under concurrent writes
• ~250k/month: archival storage costs overtaking compute
• ~400k/month: search across historical consultations becoming the slowest path in the product

The one thing we would do differently

Design the archival tier on day one. Clinical records have a retention obligation measured in years and an access pattern measured in weeks — after about a fortnight, a consultation record is almost never read again, but it must remain retrievable and auditable for a decade. Retrofitting that separation at 250,000 records a month meant a six-week migration under a live compliance obligation. At 8,000 a month it would have been a design decision costing a fortnight.

Scheduling was the hard part

Not the video. Everyone assumes real-time media is the difficult subsystem; in practice the SDK vendor absorbs most of that difficulty. The genuinely hard problem was clinician scheduling under concurrency — overlapping availability rules, cancellations, regional licensing constraints and a booking flow where two patients could reach the same slot within milliseconds. We ended up with optimistic locking on slot claims plus a compensating workflow, after a version with pessimistic locks that made the booking page feel broken under load.

The organisational scaling

By month nine the client's own team of five was the bottleneck, not the system. We stood up a dedicated development centre of eighteen engineers under their brand, running their ceremonies. The technical decisions in this article took eighteen months; the decision to grow the team took four, and every week of that delay showed up later as deferred work.