When someone says "build for scale," most engineers think about handling more HTTP requests. But when you're designing a healthcare platform meant to serve 170 million people — connecting 700+ hospitals, 120,000 pharmacies, and 15,000 diagnostic centers — scale means something entirely different. It means handling complexity. Complexity in data models, in user roles, in regulatory requirements, and in the sheer diversity of how different institutions operate.
The architecture decisions we made early defined everything. We chose an API Gateway pattern with ten NestJS microservices behind it, each owning its own data schema. FHIR compliance wasn't optional — it was the foundation. Every patient record, every prescription, every lab result had to be interoperable across the entire ecosystem. We built three separate Next.js portals: one for patients, one for providers, and one for administrators. Each had radically different UX requirements, and trying to serve them from a single frontend would have been a mistake.
The lesson that hit hardest was about failure planning. At this scale, something is always failing. A pharmacy in a rural area loses connectivity mid-transaction. A hospital's integration sends malformed data. A payment gateway times out during peak hours. We designed every service to degrade gracefully — queuing operations when downstream services were unavailable, retrying with exponential backoff, and never losing patient data even when things went wrong.
But the most humbling part wasn't the technology. It was remembering that many of the patients using this system might be interacting with a digital healthcare platform for the first time. Every screen had to be simple. Every error message had to be human. Every flow had to work on a low-end phone with a slow connection. Building for 170 million users taught me that true scale isn't about infrastructure — it's about empathy encoded into every architectural decision.