Building for 10x scale: our tech stack and architecture
We currently serve 1.8M bookings. We're building for 18M. Here's a technical deep dive into our architecture, the choices we made, and what we'd do differently.
When we started VanHub, we made a conscious choice: build for 10x our current scale from day one. Not because we expected to grow that fast (though we did), but because rewriting your stack mid-growth is the most expensive mistake a startup can make. So we chose technologies that scale horizontally and architecture patterns that don't break under load.
Our stack: Next.js 16 with App Router for the web app (SSR + ISR for SEO), React Native for the pro app, Node.js with Fastify for the API layer, PostgreSQL for transactional data, Redis for caching and session management, and Prisma as our ORM. We deploy on AWS (Mumbai region for latency), use Cloudflare for CDN and DDoS protection, and send everything to Datadog for monitoring.
The most important architectural decision we made was to keep the API stateless and horizontally scalable. Every API request carries its own auth token (JWT), and we never store session state on the server. This means we can add more API instances behind the load balancer without any code changes. During our last major sale event, we scaled from 4 to 32 API instances in 90 seconds — zero downtime.
For the database, we use PostgreSQL with read replicas. Writes go to the primary, reads go to replicas. We use Prisma's connection pooling to manage database connections efficiently. Our largest table (bookings) has 1.8M rows and growing — we partition it by month for query performance. We also use Redis aggressively for caching: service catalogs, pro profiles, and pricing data are all cached with 5-minute TTLs.
What would we do differently? Three things. First, we'd start with a message queue (Kafka or RabbitMQ) from day one — we added it late and had to retrofit async processing for notifications and payouts. Second, we'd invest more in observability early. We started with basic logging and moved to Datadog after six months; we lost visibility into early performance issues. Third, we'd think harder about data privacy from the start — our DPDP Act compliance work in 2025 was harder than it needed to be because we hadn't designed for it.
If you're an engineer reading this and want to help us build for the next 10x, we're hiring. Check our Careers page — we have open roles in frontend, backend, mobile, data science, and ML. The problems are hard, the scale is real, and the impact is measurable. Every booking that completes smoothly is a family that got their problem solved. That's what we build for.
