Lynor

I built Lynor as a real e-commerce backend, not a demo. The initial product direction is a minimalist lifestyle brand, but the architecture is designed to eventually support a multi-tenant platform for Bangladesh, where cash-on-delivery and a Division > District > Thana address hierarchy are the norm.

The interesting constraint is not the storefront. It is what happens after checkout. Orders and inventory have to stay consistent when a request fails halfway through, when a background job retries, and when two users hit the last item at the same time. Most of the work went into getting those pieces right.

The stack is NestJS with Prisma and PostgreSQL. Redis handles caching, BullMQ handles background work, and the client is a Next.js app. The choice to use Turborepo with a separate backend and frontend, rather than a Next.js full-stack setup, was deliberate.

Order and inventory writes run inside transactions, with consistency boundaries made explicit. A failed order cannot leave stock decremented.

BullMQ jobs use retry-safe, idempotent handlers. A retried job cannot double-apply a payment or a stock deduction.

Redis caching uses explicit invalidation on mutable data. Cache misses are intentional, not accidental staleness.

PostgreSQL indexes and query-level optimizations target the hot read paths: catalog listing, product detail, order history.

The address model uses the Bangladesh Division > District > Thana hierarchy directly in the schema, rather than forcing it into a generic address format.