Teaching case. This case is a composite based on typical Nepali businesses. Names are withheld and the figures are illustrative, chosen to make the calculations realistic.

Overview

Festival spikes caused app/API slowdowns and order failures. The platform implemented layered caching, autoscaling, and queue‑based workflows to stabilize.

Background

On normal evenings the platform handled a steady flow of orders from Kathmandu, Lalitpur, and Bhaktapur. During Dashain and Tihar, and on New Year’s Eve, orders arrived in sudden bursts: thousands of users opened the app within minutes, restaurants were overloaded, and riders were scarce. The app slowed, payments timed out, and some orders were accepted but never sent to the restaurant. Customers blamed the platform publicly on social media.

Key Strategies for Scaling

  • Layered Caching (The Web Layer): Static assets (menus, photos) are cached at the Edge (CDN) to offload the origin server. For dynamic data like daily specials, Server-side Caching (Redis) is used to avoid repeated database hits.
  • Message Queues for Order Events: To handle spikes, the platform moved to an Asynchronous Architecture. When an order is placed, it enters a queue (e.g., RabbitMQ/Kafka). The dispatch system processes the queue as riders become available, preventing the application server from crashing under load.
  • Database Optimization: Use of Read Replicas for non-critical tasks (browsing menus) and Connection Pooling to manage high concurrent user sessions.
  • Dispatch Optimization & Traffic Shaping: Software uses Geofencing to limit orders to areas with available riders. During extreme peaks, “Traffic Shaping” (pausing new orders or increasing delivery fees) is used to maintain service for existing orders.

Outcomes

  • Performance Stability: P95 latency (the response time for 95% of requests) improved by 45% during peak festival hours.
  • Resilience: Failed orders due to system timeouts were reduced by 70%, directly improving customer trust.
  • Operational Efficiency: Automated “batching” allowed a smaller rider fleet to handle a higher volume of orders through optimized routing.

Lessons (Unit 3 Lens)

  • Caching + Queues are Fundamental: Under bursty, location-dependent traffic, standard web servers are insufficient without asynchronous processing.
  • Separate Read vs. Write Paths: High-traffic e-commerce systems must prioritize “Reading” (browsing) performance via caches, so the “Write” (order placement) resources are protected.
  • Logistics is the Final Bottleneck: No matter how fast the web server is, the “Last-Mile” (the physical delivery) remains the most fragile part of the value chain.

The Numbers

  • Normal peak: 300 orders an hour. Festival peak: 1,500 orders an hour, five times normal.
  • Before the changes, 8% of festival orders failed; after, 2.4%, a 70% reduction.
  • At an average order of Rs. 900, failed orders fell from 120 to 36 an hour at peak: 84 × 900 = about Rs. 75,600 of extra orders an hour.
  • Menu pages served from a CDN cache no longer hit the main database, freeing it for order placement.

Case Questions

  1. Explain how caching and a content delivery network reduce the load on the platform’s servers.
  2. Why does a message queue protect the system when orders arrive faster than they can be processed?
  3. The case says logistics is the final bottleneck. Explain this with reference to riders and restaurants.
  4. Is it fair to raise delivery fees or pause orders during peaks (traffic shaping)? Discuss from the customer’s and the business’s viewpoint.
  5. What should the platform monitor before the next festival to know whether it is ready?

Chapters covered

Use the unit notes below to review the theory this case applies in practice.