Bytesnitch

Case study

Quick-commerce platform

A quick-commerce platform for a dark-store catalog, a Redis cart, and rider dispatch. Checkout is mock card, UPI, cash, or a wallet, not a live processor.

Illustrative example of a quick-commerce grocery app showcase with home, category, product, cart and profile screens.

Summary

A dark-store catalog, a short-lived cart, and rider dispatch for customer, vendor, and partner apps on one API. Checkout is an in-process mock card and UPI path, cash on delivery, or a wallet. It is not a live payment processor.

Role. The engineering notes record this as an end-to-end quick-commerce system: requirements, design, implementation, and operations. The product name in those notes is Rashmart.

Outcome. The running system is a catalog, a Redis cart, a Postgres order machine, and a partner hub that offers the nearest rider first-come. Maps use Photon and OpenStreetMap. Media uses MinIO. OTP uses MSG91. No live payment processor is attached.

The business gap

The gap

Quick commerce splits the catalog, the cart, the order, and the rider. A basket can sit apart from the pick, and a nearby rider can miss the job.

Why it was built

The notes describe one system that had to serve the customer storefront, vendor and admin operations, and a partner rider app from a single API.

How the build closed it

One Fastify and Socket.IO API holds the catalog and checkout. The cart lives in Redis as cart:{userId} with a seven-day TTL. Checkout writes a Postgres order that moves through PENDING_PAYMENT, CONFIRMED, PICKING, PACKED, DISPATCHED, and DELIVERED. Stock is checked at checkout, and the maximum quantity is 10. The partner hub offers the nearest rider first-come. Maps come from Photon and OpenStreetMap. Media is on MinIO. OTP is MSG91. Checkout stays an in-process mock, cash on delivery, or a wallet. A PostGIS image is in Compose, but serviceability queries are Haversine, not geography. A Firebase environment exists with no send path. Socket.IO is a single process, with no Redis adapter, so horizontal scale is outside this scope.

Architecture

The source notes describe this system as a graph, not as a picture file. The diagram below is that graph: every box and every link is a node or an edge from the notes.

Customer web +ExpoClientAdmin / vendorClientPartner ExpoClientFastify +Socket.IOAPIPostgresDataRedis cartDataMinIODataPhoton + OSMExternalMSG91 / DLTExternalMock card / UPIExternal
Redis cart, then the order machine, then a first-come rider hub. Socket.IO is single-process.
  • Client
  • API
  • Queue
  • Data
  • External

Parts

  • Customer web + Expo: Storefront, Redis-backed cart, and maps.
  • Admin / vendor: Vite and Capacitor catalog, inventory, and wallets.
  • Partner Expo: Rider hub, GPS throttle, and first-come accept.
  • Fastify + Socket.IO: Catalog, checkout, dispatch, and JWT roles.
  • Postgres: A PostGIS image is present. Serviceability is Haversine.
  • Redis cart: cart:{userId} with a seven-day TTL, OTP, and five-minute idempotency.
  • MinIO: Product images and Sharp thumbnails.
  • Photon + OSM: Geocode and raster tiles.
  • MSG91 / DLT: OTP SMS.
  • Mock card / UPI: In-process mock, plus cash on delivery and a wallet. Not a live processor.

Connections

  • Customer web + Expo to Fastify + Socket.IO: place order.
  • Admin / vendor to Fastify + Socket.IO: ops.
  • Partner Expo to Fastify + Socket.IO: GPS / accept.
  • Fastify + Socket.IO to Postgres: order transaction.
  • Fastify + Socket.IO to Redis cart: cart.
  • Fastify + Socket.IO to MinIO: media.
  • Fastify + Socket.IO to Photon + OSM: geocode.
  • Fastify + Socket.IO to MSG91 / DLT: OTP.
  • Fastify + Socket.IO to Mock card / UPI: mock charge.

High-level design

  • Three audiences share one Fastify and Socket.IO API: customer web and Expo, vendor and admin, and partner Expo.
  • The cart lives in Redis. Checkout writes a Postgres order and offers the nearest rider first-come.
  • Photon and OpenStreetMap supply maps. MinIO stores media. MSG91 sends OTP. The processor is mock card and UPI, plus cash on delivery and a wallet.

Low-level design

  • The order machine runs PENDING_PAYMENT, then CONFIRMED, PICKING, PACKED, DISPATCHED, and DELIVERED.
  • Redis cart:{userId} has a seven-day TTL. Stock is checked at checkout. Maximum quantity is 10.
  • The partner hub auto-offers work. Socket.IO GPS is throttled. The socket server is a single process, with no Redis adapter.

Infrastructure and services

  • Postgres. A PostGIS image is present. Serviceability is Haversine.
  • Redis cart. cart:{userId} with a seven-day TTL, OTP, and five-minute idempotency.
  • MinIO. Product images and Sharp thumbnails.
  • Photon + OSM. Geocode and raster tiles.
  • MSG91 / DLT. OTP SMS.
  • Mock card / UPI. In-process mock, plus cash on delivery and a wallet. Not a live processor.

Tech stack

  • Fastify logoFastify
  • Prisma logoPrisma
  • PostgreSQL logoPostgreSQL
  • Redis logoRedis
  • Socket.IO logoSocket.IO
  • MinIO logoMinIO
  • Expo logoExpo
  • Capacitor logoCapacitor
  • OpenStreetMap logoOpenStreetMap
  • Photon
  • MSG91

Logos are Simple Icons shipped with this site. Where a brand mark is unavailable, the name is shown on its own.

Client review

Catalog, cart and rider dispatch finally sit in one place. Dark-store ops can see stock and hand-offs without jumping between three tools.

Head of operations, grocery retail

Client testimonial

The store flow was clear enough for our floor leads on day one. Checkout stayed labelled for the pilot, which kept finance calm.

Store operations lead

Constraints in the source

  • A PostGIS image is in Compose. Serviceability queries are Haversine, not geography.
  • A Firebase environment exists. There is no send path. Horizontal scale is blocked by Socket.IO.

All projectsDiscuss a projectServices