It's Amazon Great Indian Sale. Midnight strikes. Millions of people hit refresh simultaneously.
Your internet slows down. The app feels laggy. You're frantically trying to add that phone to your cart before it goes out of stock.
And somehow Amazon doesn't crash.
Millions of orders. Milliseconds apart. Payments processing. Inventory updating. Warehouses getting notified. Delivery partners being assigned.
All at once.
How does any system survive that?
Here's the engineering behind it.
The Scale That Will Surprise You
Amazon Prime Day 2024 over 200 million items sold in 48 hours.
That's roughly 1.4 million items per minute. 23,000 items per second. At peak.
Each item involves:
- Checking inventory
- Processing payment
- Updating stock count
- Notifying the warehouse
- Scheduling delivery
- Sending confirmation email
- Updating the seller dashboard
Multiply that by 23,000 every second.
This is not a website problem. This is one of the hardest engineering challenges in the world.
Why Normal Architecture Fails on Sale Day
A normal web application works like this:
User places order → Server processes it → Database updates inventory →
Confirmation sent.
That works for 100 orders a minute. At 23,000 orders a second — the database becomes a bottleneck.
Every order needs to read inventory. Every order needs to write a new count. Every order needs to check payment.
All hitting the same database. At the same time. The database collapses.
The website goes down.
Amazon cannot afford that. Not on sale day. Not ever.
So they built something completely different.
🏗️ Microservices - Breaking the Monolith
Amazon was one of the first companies to move from a single large application to microservices.
Instead of one giant system hundreds of small independent services.
Each service does one thing:
- Inventory Service = manages stock counts
- Order Service = creates and tracks orders
- Payment Service = processes transactions
- Notification Service = sends emails and SMS
- Recommendation Service = suggests products
- Search Service = handles queries
- Delivery Service = assigns and tracks shipments
Each service runs independently. Each can scale independently. If the Notification Service crashes orders still process. If the Recommendation Service slows checkout still works.
One service failing doesn't take down everything.
📦 The Cart Problem - Eventual Consistency
Here's a tricky problem:
You add a phone to your cart. Your friend adds the same phone to their cart. There's only one phone in stock.
Who gets it?
Amazon uses a concept called eventual consistency for carts.
Your cart is not immediately checked against live inventory.
Adding to cart is fast and always works. The real inventory check happens at checkout.
This is why you can add something to your cart and then find it's out of stock when you pay.
The cart is optimistic. Checkout is the reality check.
This design choice makes the browsing experience fast for everyone even when millions are shopping simultaneously.
⚡ Message Queues - Why Orders Don't Get Lost
When you place an order Amazon doesn't process everything synchronously.
Instead your order goes into a queue.
Think of it like a token system at a hospital. You get your token number. You wait. The doctor sees patients one by one.
Amazon's order queue works similarly:
Your order confirmation appears immediately. Behind the scenes your order enters a queue. Warehouse notification - queued. Payment processing - queued. Email confirmation - queued.
Each gets processed in order. No step gets skipped. No order gets lost.
Even if one service is temporarily slow the queue holds the work until that service catches up.
Amazon uses AWS SQS and Kafka for this message queue infrastructure.
🗄️ Database Sharding - Splitting the Load
One database cannot handle millions of reads and writes per second.
Amazon splits its databases into smaller pieces called shards.
Instead of one inventory database thousands of smaller ones. Each shard handles a portion of products.
Electronics inventory - one set of shards.
Clothing inventory - another set.
Books - another set.
When you check stock for a phone only the electronics shard is queried.
Not the entire inventory database.
The load is distributed. No single database gets overwhelmed.
🌍 Content Delivery Networks - Speed Everywhere
You're in Nashik.
Amazon's main servers are in Mumbai and Chennai.
When you load Amazon product images, CSS files, JavaScript these don't come from Mumbai.
They come from the nearest CDN node. Amazon CloudFront has edge locations across India and the world.
Static content is cached at these edge locations. Your browser fetches images from a server that might be just a few hundred kilometers away not thousands.
Pages load fast. Regardless of where you are.
💳 Payment Processing - The Most Critical Path
Payment is where Amazon cannot fail.
When you hit Pay Now the payment goes through a completely separate high-availability system.
Multiple payment processors on standby. If one fails another takes over instantly. No single point of failure.
Payment data is encrypted end to end. Stored in compliance with PCI DSS standards the global security standard for payment card data.
Transactions are idempotent meaning if you accidentally click Pay twice,
the second click is recognised as a duplicate and only one payment goes through.
🏭 Warehouse Automation - Where Digital Meets Physical
Your order is placed. Now the physical world has to respond.
Amazon warehouses use:
Robots - Kiva robots move entire shelves
of products to human pickers.
Workers don't walk to find items.
Items come to workers.
Computer Vision - cameras identify products,
verify they're the right item,
check for damage.
Conveyor Systems - automated sorting
sends each package to the right
shipping carrier automatically.
Real-time Tracking - every package
gets a barcode scanned at multiple points.
That's how you see "Out for Delivery"
update on your phone in real time.
📊 The Honest Summary
| Problem | Amazon's Solution |
|---|---|
| Too many requests at once | Microservices — each scales independently |
| Cart conflicts on low stock | Eventual consistency — check at checkout |
| Orders getting lost under load | Message queues — nothing processed out of order |
| Database bottleneck | Sharding — split across thousands of databases |
| Slow page loads globally | CDN — content cached near every user |
| Payment failures | Multiple redundant payment processors |
| Warehouse efficiency | Robots + computer vision + automated sorting |
Why This Matters for Developers
Every concept Amazon uses microservices, message queues, sharding, CDN, eventual consistency
These are not Amazon-only technologies.
They are available to every developer through AWS, the same cloud infrastructure Amazon built for itself and then opened to the world.
The difference between Amazon's scale and a student project is not the technology.
It's the experience of knowing when and why to use each piece.
Understanding why Amazon shards its databases makes you a better developer when you design your own.
Understanding why they use message queues makes you reach for queues when your own system needs reliability.
The engineering behind the world's biggest e-commerce platform is a textbook for building anything. 😊
What surprised you most about how Amazon handles sale day traffic?
Or have you ever worked on a system that needed to handle high traffic?
Drop it below 👇
Top comments (0)