Stop 22 · Build Backend Portfolio ProjectsProjects · 3/14

E-commerce Backend

In short

Products, carts, orders, stock and payments: an e-commerce backend is where race conditions and money bugs show up. Handle them well and recruiters notice.

A backend for an online store — products, cart, orders, inventory and checkout — one of the most résumé-relevant, feature-rich backend projects you can build.

The purple blob shopkeeper ticks a stock register while a customer fills a basket.

Think of it like this

A kirana store goes online

Uncle keeps a stock register, puts your items aside, makes the bill and only hands over the bag after you pay. If two customers want the last Maggi packet, only one gets it. Your backend has to do all of this, correctly, for thousands at once.

Watch it happen

Placing an order

App

Order API

Postgres

Payments

POST /orders

1/7The app sends only product IDs and quantities. Never prices.

The big ideas

What you need to know

Products and inventory

Products with variants, prices and stock. Stock changes must be atomic so two buyers can't both get the last unit.

Cart and checkout

The cart can be loose, but checkout re-reads prices and stock from the database.

Order state machine

pending_payment, paid, shipped, delivered, cancelled. Allow only valid moves between states.

Money as integers

Store amounts in paise as integers. 0.1 + 0.2 isn't 0.3 in floating point.

See it in code

Walk through the code

sql

1BEGIN;2 3-- Reserve stock only if enough is left. Two buyers can't both get the last unit.4UPDATE products5SET stock = stock - 26WHERE id = 42 AND stock >= 2;7-- If 0 rows were updated: ROLLBACK and reply "out of stock"8 9INSERT INTO orders (user_id, status, total_paise)10VALUES (7, 'pending_payment', 199800)11RETURNING id;12 13COMMIT;

1/3One atomic statement: reduce stock only where at least 2 are left.

The check and the decrement happen in one UPDATE, so the database itself prevents overselling. ₹1,998 is stored as 199800 paise.

Save yourself the pain

Common mistakes

Oops

Reading stock, checking it in JavaScript, then writing the new value.

Do this instead

Two requests can read the same stock at once. Do the check inside the UPDATE, or lock the row.

Oops

Trusting the price or total sent by the client.

Do this instead

Always read prices from your database at checkout and calculate the total on the server.

Your mission

Milestone 1: no overselling

~45 min

Quick check

Why use UPDATE ... SET stock = stock - 1 WHERE stock >= 1 instead of reading stock first in code?

Go deeper

1Model inventory correctly so overselling out-of-stock items isn't possible under concurrent orders.
2Implement the full order lifecycle: cart → checkout → payment → fulfillment.
3Add an admin API for managing products and viewing orders.

More projects at this stop