Amazon Checkout System Design Explained in 2 Minutes

Added: 2026-05-22

[00:00:00]Today, I want your opinion on famous system design problem.

[00:00:03]Let's consider an Amazon style online shopping system.

[00:00:06]You add all the items you need in the cart and then click place order and the website confirms if your order is placed.

[00:00:12]Behind that place order button, the system has to finish six different jobs.

[00:00:16]First, it has to charge your credit card. Then, hold the item in the warehouse so nobody else buys the last one.

[00:00:23]Next, we save this order to the database.

[00:00:26]Fourth task is to send a confirmation email.

[00:00:28]Fifth is to tell the warehouse what product needs to be shipped. And the last one is to update your product recommendations so that we can suggest similar or related items next time.

[00:00:37]The question is, how do you arrange those six jobs?

[00:00:41]Option A is to do them all in a single line, one after another.

[00:00:44]First, we charge the card, then reserve the item, then save the order to database, then send the email, then notify the warehouse, then update recommendations.

[00:00:54]The website only says order placed after every single step finishes.

[00:00:58]The problem is that it takes significantly more time for user to see the confirmation on website.

[00:01:03]For example, if it takes 200 milliseconds for payment, 150 milliseconds to reserve items and so on, then we are looking at a 1 and 1/2 second wait every time someone clicks that button.

[00:01:12]And if any single step breaks, let's say the email service is having a bad day, the whole thing fails and user will see an error on website.

[00:01:20]But the truth is that some of the steps might have already succeeded. The payment may have already gone through.

[00:01:25]The order may already have been saved.

[00:01:27]Therefore, the customer is charged but doesn't know if their order worked because website shows error and customer tries to place the order again.

[00:01:34]Now you've got duplicate orders to clean up.

[00:01:37]Option B is a little smarter.

[00:01:39]We only do the must finish jobs in line like charging the card and saving the order.

[00:01:43]The user sees order placed once these must finish jobs are done.

[00:01:47]Everything else like sending the email, the warehouse notification, and product recommendations gets pushed onto a background job queue.

[00:01:54]Then background programs pick these jobs up and finish them when they can.

[00:01:58]This is much faster for the user.

[00:02:00]But here's the issue.

[00:02:01]One day, the background program that sends emails just stops working.

[00:02:05]The customer saw order placed on the website, but never gets a confirmation email.

[00:02:10]So, they start calling support asking, "Did my order actually go through?"

[00:02:14]And you don't even notice the email program is broken until the support tickets start piling up.

[00:02:19]Now, the real question isn't about do everything at once or do some things later.

[00:02:24]The question is, what absolutely must finish before you can honestly tell the user that your order is placed?

[00:02:29]And which tasks can actually happen later safely as long as they eventually gets done?

[00:02:34]Let me know your thoughts in comment section.