MarketHive: The E-commerce Backend That Treats Checkout Like a Concurrency Problem

A Node.js commerce API with Redis token blacklisting, transactional order logic, and stock locks that keep the cart honest when real users hit it at once.

8 to 10 min read • View on GitHub • More from pranav511

A warehouse checkout counter is held in place by a heavy mechanical lock while a clerk stamps a ledger and a hand reaches for the last item on a shelf. The scene explains that MarketHive is built to prevent overselling by making checkout an atomic coordination problem, not a simple form submission. — When the last unit matters, checkout becomes a locking problem.

Key Takeaways

MarketHive stands out because it treats checkout as a concurrency problem first and a commerce flow second.
Its strongest patterns are defensive ones: transaction boundaries, row locks, token blacklisting, and rollback-safe registration.
The project is most interesting where it avoids embarrassing failures, not where it adds storefront features.
The data model and service layout are built to absorb real-world complexity without turning the codebase into a demo.

The checkout problem no one sees until it breaks

E-commerce looks straightforward until two people try to buy the last unit at the same time. That is where MarketHive gets interesting. It does not treat checkout as a form that writes rows. It treats checkout as a race that has to be controlled.

The project’s core instinct is defensive. Registration can roll back if OTP delivery fails. Authentication can invalidate sessions in Redis. Order creation uses a database transaction and row locks so stock cannot be oversold just because two requests arrived together.

The important thing is not that MarketHive can place an order. It is that it can place one correctly when timing gets messy.

What MarketHive is actually built to protect

MarketHive is a service-oriented Node.js backend for an Admin, Seller, and Customer workflow. The stack is practical rather than trendy: Express, MySQL, Redis, Joi, AWS S3, Razorpay, Twilio, Nodemailer, and JWT with bcrypt for identity. That mix matters because it shows up in the places where commerce systems tend to fail.

The codebase is organized around controllers, services, middleware, config, validators, and jobs. That separation is not decorative. It makes the business logic live in the service layer, where transactional behavior can be written and tested without smearing it across route handlers.

Two stacked inventory ledgers are secured by separate padlocks, one representing product-level stock and the other variant-level stock. A single order form sits to the side, blocked until both locks are held, illustrating the double-lock stock validation pattern used to prevent overselling. — MarketHive validates stock at more than one level because real inventory is rarely flat.

Inside createOrder: the real center of gravity

This is the part of the project that makes the thesis true. The order flow begins a transaction, checks product stock, checks variant stock, applies shipping and coupon logic, creates the order, moves cart data into order items, and then commits everything together. If anything fails, it rolls back.

START TRANSACTION;
SELECT stock FROM products WHERE id = ? FOR UPDATE;
SELECT stock FROM product_variants WHERE id = ? FOR UPDATE;
-- validate quantities, apply coupon, compute shipping
INSERT INTO orders (...);
INSERT INTO order_items (...);
DELETE FROM cart_items WHERE user_id = ?;
COMMIT;

The key detail is `FOR UPDATE`. That lock tells the database to hold the rows until the transaction ends, which keeps a second checkout from sneaking in and claiming the same inventory. The double stock check is not redundancy for its own sake. It is a deliberate hedge against how inventory is modeled.

That makes MarketHive feel different from the average demo backend. The happy path is not the achievement. The achievement is that the unhappy path still leaves the system consistent.

Why authentication is not just JWT

MarketHive uses access and refresh tokens, but it does not stop at stateless token issuance. It stores refresh tokens and session IDs in Redis, and it blacklists access tokens on logout for the remainder of their TTL. That means logout actually means something.

const sessionId = uuidv4();
await redis.set(`session:${sessionId}`, refreshToken);
await redis.set(`blacklist:${accessToken}`, '1', 'EX', ttl);

// later
if (await redis.get(`blacklist:${token}`)) {
  throw new Error('Token revoked');
}

This is a stronger pattern than the naive version most hobby projects ship with. A purely stateless JWT setup is easy to build, but hard to revoke cleanly. MarketHive chooses operational control over simplicity, which is usually the right trade when payments and accounts are involved.

The data model is doing a lot of quiet work

The catalog is not just a list of products. It supports variants with price adjustments, which is the difference between a toy storefront and a system that can represent size, color, or configuration without collapsing into special cases.

There is also a hybrid storage story. The code shows local uploads, but the structure is ready for S3. That is a small signal, but a meaningful one. It suggests the project is built with the assumption that the storage story may have to grow up later.

The schema itself is normalized and uses foreign keys and enums to keep the relationships explicit. That is not glamorous work, but commerce systems live or die by these unglamorous boundaries.

MarketHive versus a typical hobby backend

Capability	Typical hobby backend	MarketHive
Order atomicity	Best-effort inserts	Single transaction from stock check to cart cleanup
Stock locking	No row-level lock	`FOR UPDATE` on product and variant rows
Variant inventory	Often ignored or flattened	Explicit variant model with price adjustments
Session storage	JWT only, no revoke path	Redis-backed refresh tokens and blacklist
Logout invalidation	Symbolic at best	Access token revocation is enforced
OTP verification	Usually email only or skipped	Email and SMS OTP with rollback on failure
Validation layer	Basic request checks	Joi validation before business logic
Failure recovery	Partial writes and manual cleanup	Transaction rollback and user cleanup paths

The point is not that MarketHive competes with enterprise commerce suites. It is that it already thinks about the failure modes that separate a demo from something you could trust under load.

What the project gets right, and what it still hints at

The strongest signal in MarketHive is its discipline. It repeatedly chooses correctness over convenience, and it does so in places that matter: stock, sessions, OTP delivery, and rollback behavior. That is exactly where real systems get expensive when they fail.

The main opportunity is abstraction. Checkout preview and order creation appear to share pricing and shipping logic, which hints at duplication that could eventually live in a shared pricing engine. That is not a flaw so much as a sign that the project is already close enough to production concerns to benefit from tighter internal boundaries.

In the end, MarketHive is not interesting because it is an e-commerce backend. It is interesting because it treats commerce as an integrity problem. That is the right instinct.