# 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](/architecture/redis-resilience/).
- **Correctness under concurrency.** Flash-sale inventory uses atomic
  reservations so a thousand simultaneous buyers cannot oversell ten units.
  See [Flash Sales](/features/flash-sales/).
- **Scale.** Cursor-based pagination, multi-layer caching, and HTTP- and
  application-level rate limiting are designed for ~20k concurrent users. See
  [Scaling](/architecture/scaling/).

## How to read this site

- **[Tech Stack](/guide/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](/blog/)** — longer narrative posts about specific build decisions.