SmartCart API
A production-ready e-commerce backend built with Node.js, TypeScript, PostgreSQL and Redis. Features JWT auth, cursor-based pagination, pessimistic locking to prevent overselling, payment webhook processing, background job queues, and transactional email.
Problem
E-commerce backends look simple until you face real concurrency — two users buying the last item simultaneously, a payment webhook firing three times, an email job silently failing. SmartCart was built to handle all of these correctly from the start, not as an afterthought.
Prior Art
I studied how Stripe handles idempotency and how PostgreSQL row-level locking behaves under concurrent transactions before writing a single line. The core insight: most e-commerce bugs come from optimistic assumptions about concurrency. SmartCart makes none.
Design Decisions
Pessimistic locking on stock — SELECT ... FOR UPDATE inside a transaction before every checkout. Overselling is impossible regardless of load.Webhook idempotency via a webhook_events table — every incoming event is recorded before processing. Duplicate webhooks are detected and discarded safely.Worker process separated from the API — emails, image resizing, and stock alerts run in a dedicated BullMQ worker. Jobs survive worker crashes and retry automatically.
Architecture
Client → Express API (controllers → services → repositories)PostgreSQL — users, products, orders, audit logsRedis — cart storage, product cache BullMQ Worker — emails, image processing, stock alerts
Reflection
Three things I'd change: move image uploads to pre-signed S3 URLs to support horizontal scaling, replace pessimistic locking with a queue-based checkout system for higher throughput, and add dedicated failure scenario tests for the webhook idempotency logic.