How Would You Scale Zomato for Doubled Concurrent Users?

Requirements: Assume Zomato's current concurrent user load doubles. Describe how you would scale the system to handle this without degrading latency or availability.

Design considerations:

• Identify likely bottlenecks first: application server CPU/connections, database read/write throughput, cache hit rate, and third-party/downstream dependencies (payments, delivery-partner services).
• Horizontal scaling of stateless application/API servers behind a load balancer, with auto-scaling policies keyed on CPU/request-latency metrics.
• Database scaling: add read replicas for read-heavy traffic (menu browsing, search), introduce/expand caching (Redis) for hot data (restaurant listings, menus) to offload the primary DB, and consider sharding write-heavy tables (orders) by region or restaurant id if a single primary becomes the bottleneck.
• Asynchronous processing: move non-critical-path work (notifications, analytics events, order-status updates) onto message queues/event streams so the request path stays fast.
• CDN and edge caching for static assets and search/listing pages where possible.
• Capacity planning and load testing to validate the scaled design actually holds at 2x load before rollout, plus graceful degradation (e.g., serving slightly stale cached restaurant data) under extreme load.