RedisMart Makes Redis the Store's Nervous System

This full-stack e-commerce repo does not just cache product pages. It uses Redis to decide who gets in, what stays fast, which coupons still count, and how the dashboard stays current.

10 min read • View on GitHub • More from evinjohnn

A wide retail storefront built around a central mechanical vault, with shelves, a checkout counter, an admin desk, and shipping lanes all connected back to one bright core. The scene explains the article's main idea: Redis is not a side cache here, it is the coordination layer that keeps the store moving. — Redis sits at the center of the shop, not off to the side. That makes speed, state, and business rules feel like one system instead of three.

Key Takeaways

RedisMart treats Redis as a coordination layer, so the store can make fast decisions before MongoDB has to get involved.
Its auth flow is the clearest example: refresh tokens live in Redis, access tokens stay short, and the frontend retries through an interceptor.
Featured products, coupons, and analytics all follow the same pattern of cache, invalidate, and recompute close to the user.
The project reads like a reference architecture for retail teams that want fewer moving parts without giving up real-time behavior.

Most e-commerce tutorials bolt Redis onto a store as a cache. RedisMart does something more useful. It makes Redis the place where the app decides who can log in, which products feel fast, which coupons still count, and what the dashboard should show.

A demo name with a different agenda

The name comes with history. Redis used RedisMart to show a real-time retail demo at RedisConf 2021, and its follow-up posts framed the project around catalog search, distributed inventory, and AI-driven shopping. That official version proves what Redis Enterprise can do at platform scale. This repo takes the same retail problem and makes it practical in a classic React, Express, MongoDB stack.

This article is the first of a series. It gives you some insights into the main requirements and the architecture of the RedisMart retail application by looking at how you can implement a product catalog, a distributed real-time inventory, and an AI-powered product search. You’ll also see how Redis Enterprise powers all those functionalities.

Dylan Kreisman, Author, Redis Blog · RedisMart architecture

Inside this repo, the interesting move is smaller and sharper. The backend is split the familiar way, with controllers, middleware, and a few service files in backend/lib for Redis, Stripe, and Cloudinary. The frontend uses React 18, Vite, Tailwind CSS, Framer Motion, and Zustand, which keeps the cart and user state global without Redux-level ceremony.

Auth is the clearest proof

The auth flow shows the design discipline. Access tokens are short lived, refresh tokens live in Redis under keys like refresh_token:${userId}, and the browser only sees HttpOnly, sameSite strict cookies. When a request comes back 401, the Axios interceptor in the frontend tries to refresh before it gives up. That makes logout, rotation, and revocation much cheaper than storing long-lived session state in the database.

A close-up of two keys on a locksmith's bench, one small and temporary, the other sealed inside a steel lockbox with a narrow slot for renewal. The scene explains how the app separates short-lived access tokens from Redis-backed refresh state so revocation stays simple. — The refresh token is not buried in a user document. It is held close, so the server can revoke it without a cleanup project.

The request path is short on purpose

A browser request does not wander through the stack. It moves through a compact set of responsibilities, with Redis handling the hot decisions and MongoDB handling the durable ones.

That split is the repo's real architecture lesson. Redis is not replacing MongoDB. It is taking the jobs that need fast answers, immediate invalidation, or shared mutable state. MongoDB still owns the source of truth, but Redis owns the tempo.

In this blog post, we’ll dive into getting you started using RedisJSON’s new JSON indexing, querying, and full-text search capabilities by looking at how it was used to build RedisMart’s product catalog service.

Adi Wabisabi, Author, Redis Blog · RedisJSON catalog

Three places Redis quietly changes the product

First, product reads use a cache-aside pattern. getFeaturedProducts checks Redis before it hits MongoDB, and the code uses .lean() when it does query, which keeps the path light. When an admin toggles featured status, the cache gets refreshed so the storefront does not drift.

Second, the payment flow turns business logic into a state machine. Stripe handles the charge, but the app also generates a unique gift coupon when the order crosses a threshold, stores it in MongoDB, and deactivates it after checkout succeeds. That is not just payments. It is product design expressed as code.

Third, analytics are built from aggregation rather than counters. The sales controller buckets orders by day with MongoDB pipelines and sends that shape straight to the charting layer. The result is boring in the best way. The frontend gets ready-to-plot data, and nobody is hand stitching numbers in the browser.

Typical tutorial store	RedisMart
Sessions and refresh state live in the database or in memory.	Refresh tokens live in Redis, which makes revocation and rotation quick.
Every product view asks the database for the same answer.	Featured products hit Redis first and fall back to MongoDB only on a miss.
Discounts are often computed in the UI.	The server issues and retires coupons as part of the checkout flow.
Analytics are often stitched together from raw counts.	Sales data comes from aggregation pipelines ready for charts.
Caching is an optimization layer.	Redis is part of the app's coordination model.

That is why the repo feels more mature than a tutorial and less heavy than a microservices platform. It keeps the stack small, but it uses Redis in places where small decisions have a big user-facing impact.