iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Serving millions of users is not just a matter of adding database servers. Swiggy’s engineering articles describe a harder problem: each app request can trigger significant computation and a cascade of calls across microservices, while sharp traffic peaks and cache failures can push more work onto persistence systems. The company’s public accounts explain the pressures and resilience practices, but do not disclose a complete current database design.
Why a food-delivery homepage can create heavy backend work
A restaurant list is not simply a database query. In a March 15, 2021 Swiggy Bytes article, engineer Vijay Seshadri describes homepage work that includes checking serviceability, estimating delivery times, selecting personalized promotions, ranking restaurants, and choosing relevant collections. Serviceability itself can depend on road access, traffic, travel time, and delivery capacity.
Those calculations can apply to many customer–restaurant combinations. Seshadri illustrated the scale with a dense Bangalore scenario: more than 1,000 serviceable restaurants and 1,000 simultaneous app opens could imply over 1 million computations per second. This was an illustration of potential work, not a verified current throughput benchmark. Swiggy Bytes
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Traffic peaks make capacity planning a moving target
In the same 2021 account, Swiggy reported that one storefront service handled roughly 100,000 requests per minute at lower load, about 300,000 around lunch, and around 500,000 at dinner. The article characterized the daily pattern as four to six peak hours and six to eight hours with practically no traffic, with weekends somewhat busier. These are dated figures for the reported service and period, not current measurements or company-wide totals.
#1 Best Overall
Provisioning every layer for the dinner peak all day can waste resources; provisioning only for quiet periods risks overload when demand rises. Seshadri described scaling compute and storage with the demand curve as more cost-effective than continuously maintaining peak capacity. That strategy depends on scaling quickly enough and on every bottleneck—not just application servers—having sufficient headroom.
How microservice fanout can amplify database load
Swiggy’s post describes hundreds of services participating in order fulfillment and parallel work used to keep page response time down. In some flows, it reported an average fanout factor of 3–5x: a request to one service can lead to several downstream requests. When separate call paths converge on the same downstream service, that tail service can receive much more traffic than the original request count suggests.
Parallel calls can reduce elapsed time when dependencies respond promptly, but they also increase concurrency and can concentrate load on shared services. A dependency slowdown can therefore become a system-wide problem unless upstream services limit or contain the effects.
Recommended Free Tools
Why caching helps—and why a cache failure can hurt
Caching can serve repeated data without making every request wait on persistence, reducing latency and database work. It introduces its own consistency problem: cached values must be kept acceptably aligned with the underlying data. Swiggy says it uses cache-coherence strategies, but its overview does not specify the protocols, so it does not support claims about a particular invalidation method.
The more dangerous case is a cache failure or a large wave of misses. Requests that normally stop at the cache can suddenly fall through to persistence. If the database cannot absorb that fallback traffic within the request’s latency budget, queues and timeouts can spread through dependent services. Seshadri warned: “However, in the event of a cache failure (or large scale cache miss), the persistence layer will be unable to service the call within the latency budget, potentially causing a cascading failure.”
Swiggy’s 2021 post described a P99 latency budget near 50 ms for several services, as part of rendering a page in a few hundred milliseconds. A P99 target concerns the slowest one percent of requests, so average latency alone would not show whether this tail is being missed. The figure is a dated example from that article, not a current universal target.
Resilience practices that keep one failure from spreading
In a November 24, 2021 article, Seshadri reported that Swiggy then operated over 400 microservices in production, with over 130 directly in the order-fulfillment path. These publication-time counts should not be read as current service totals. The article distinguishes a blackout, where dependency requests fail, from a brownout, where some requests still succeed or responses miss their latency targets. Designing Resilient Microservices — Part 1
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteLocalize faults with circuit breakers
A circuit breaker monitors a dependency’s failure behavior and can stop repeatedly sending calls when that dependency is struggling. The purpose is containment: avoid spending more time and capacity on a service that is unlikely to respond, and give it room to recover. A breaker does not repair the dependency; it helps prevent its failure from consuming resources throughout the call graph.
Rank #3
Use retries carefully
Retries can help with brief transient errors, but retrying every failed request immediately increases load precisely when a dependency is under stress. Seshadri cautioned, “A misconfigured retry logic can actually take a service under stress (in brownout) to a blackout.” Retries therefore need limits and must fit inside the caller’s overall deadline; otherwise, recovery attempts can become an amplifier.
Degrade gracefully when exact data is unavailable
Some requests can still be useful with an approximation or reduced feature set. Swiggy’s article gives estimating a delivery agent’s location as an example when an exact-location dependency is temporarily unavailable, provided the estimate meets a timing threshold. The broader principle is to preserve the core customer action while avoiding an indefinite wait for a nonessential dependency.
Allocate latency against the whole request deadline
A page-level deadline is shared across its dependencies. Giving every downstream call a generous independent timeout can make the combined request exceed the user-facing budget. Swiggy’s article discusses adaptive resilience: allocate latency dynamically based on observed dependency behavior while preserving the top-level deadline. It explains a design approach, not every detail of Swiggy’s production implementation.
Where sharding and replicas fit—and what is not known about Swiggy
Sharding is a general technique for distributing a dataset across multiple machines. It can increase capacity when one database cannot serve the workload, but it requires choosing how records are partitioned and handling the resulting operational complexity. It is not a cure for inefficient requests, uncontrolled fanout, or a cache outage that overwhelms the remaining database capacity.
Meta Engineering’s August 24, 2020 article explains why databases are harder to scale than stateless web tiers: data has state and must be distributed. It contrasts modulo hashing—which can require broad redistribution when servers are added—with consistent hashing, which can limit the subset that moves but has limitations for constraints such as geographic placement. Meta also describes explicit shard allocation, replica roles, failover, load balancing, and changing replication factors. These are Meta’s general design examples, not evidence of Swiggy’s architecture. Meta Engineering: Scaling the Facebook Data Warehouse
Read replicas can distribute eligible reads in some architectures, but they introduce routing decisions and replication lag: a replica may not yet reflect a recent write. Whether caching, replicas, or sharding is appropriate depends on the read/write mix, consistency needs, latency target, failure behavior, operational capacity, and cost.
The Swiggy sources discussed here do not identify its database vendor, current database topology, shard strategy, replica setup, cache product, or cloud provider. They support an explanation of the workload and resilience challenges—not a reverse-engineered database blueprint.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →The practical lesson: protect the persistence layer from surprise work
Swiggy’s public engineering accounts point to a connected set of controls: scale with demand, understand how calls multiply across services, keep cache behavior coherent, and contain dependency failures. The key database risk is often not ordinary request volume alone, but sudden extra work caused by traffic peaks, fanout, retries, or cache misses. A resilient design plans for those paths as carefully as it plans for normal operation.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
