Introduction
Ecommerce App is a production-grade online commerce platform built on Rails 8.1. It started as a standard storefront and grew into a system that handles the hard parts of commerce: inventory that must never oversell, payments that must reconcile to the cent, infrastructure that degrades gracefully instead of failing hard, and marketing automation that runs on a fleet of background jobs.
This site is a curated walkthrough of how it was built — written for other engineers who want to see the design decisions, not just the feature list.
The shape of the system
It is a Rails monolith, deliberately. Server-rendered ERB views, enhanced with
Hotwire (Turbo + Stimulus) and ViewComponent, give an interactive UI without a
separate front-end application. Business logic lives in service objects
(over 130 of them) rather than fat models or controllers; each returns a
predictable { success:, message:, errors: } result.
Browser ──▶ Rails controllers ──▶ Service objects ──▶ Models / PostgreSQL
▲ │ │
│ ▼ ▼
Turbo ViewComponents Background jobs (Solid Queue + Sidekiq)
Streams │
▼
Redis · AWS SES · payment gateways
What it does
| Area | Highlights |
|---|---|
| Shopping | Catalog, cart, checkout, coupons, gift cards, loyalty points |
| Wishlists | Collaborative wishlists, sharing, followers, gift purchases, price alerts |
| Discovery | Semantic search, category/tag recommendations, recently viewed |
| Promotions | Flash sales with atomic inventory, time-boxed discounts |
| Payments | Razorpay + PayU gateways, settlements, refunds, reconciliation |
| Sellers | Vendor onboarding with KYC, multi-store dashboards, payouts |
| Marketing | Email campaigns over AWS SES, newsletters, abandoned-cart recovery |
| Content | SEO blog platform with a rich-text editor and scheduling |
What makes it interesting
Most of the engineering effort went into the parts a feature list doesn’t show:
- Failure tolerance. Redis is a fail-open dependency everywhere. A down cache degrades the experience but never returns a 500, and the health check is designed so the load balancer never pulls a node that is still serving traffic. See Redis Resilience.
- Correctness under concurrency. Flash-sale inventory uses atomic reservations so a thousand simultaneous buyers cannot oversell ten units. See Flash Sales.
- Scale. Cursor-based pagination, multi-layer caching, and HTTP- and application-level rate limiting are designed for ~20k concurrent users. See Scaling.
How to read this site
- Tech Stack — the tools and why they were chosen.
- Features — what the platform does, one subsystem per page.
- Architecture & Scale — how it stays fast, correct, and available.
- Blog — longer narrative posts about specific build decisions.