Ready for your busiest day: How we scale

Summary

Fin describes how its customer service platform is designed to absorb high-volume events while preserving customer isolation, availability, and operational control. At daily peaks, it handles over 150,000 customer requests per second and more than 70,000 asynchronous requests per second; its source-of-truth data spans 128 Vitess shards, while Elasticsearch supports over 650TB, 1.7 trillion documents, and peaks above 40,000 requests per second. The architecture favors AWS primitives, Vitess managed by PlanetScale, online and incremental migrations, fair queues, feature flags, heartbeat metrics, and automatic rollback, with roughly 250 production ships per workday and merge-to-production time under 10 minutes. The stated conclusion is that scale depends less on headline capacity than on clear scaling levers, tenant fairness, customer-outcome monitoring, reversible change, and routine infrastructure improvement without planned customer-impacting downtime.

Takeaways

1. 1

   The source-of-truth database is distributed across 128 Vitess shards and handles around two million requests per second, with more than ten million cache reads per second in front of it.

2. 2

   Elasticsearch supports more than 650TB of storage and 1.7 trillion documents, with index reshaping performed through partitioning, dual-writing, backfilling, validation, and gradual customer migration.

3. 3

   The operating model treats smaller, reversible production changes, heartbeat-driven detection, and automatic rollback as part of reliability, alongside a goal of avoiding routine customer-impacting maintenance windows.