AR Avinash Rapolu ← Back to the story

Case study · a solo build

A Hybris-grade headless commerce platform, built end to end.

Capsule Commerce — a Spring Boot 4 commerce backend with an OpenSearch + LLM search stack, a promotion engine, a business-process engine, and a React backoffice. Architected, built, and adversarially audited by one engineer.

~57k lines of code 597 backend tests · 0 failing 4 modules — Java core/payment/search + Python AI 20+ feature domains
▶ Live demo — coming soon See what it does ↓ Engineering rigor

What it is

A commerce platform, not a demo store

Capsule Commerce is a headless, API-first commerce platform in the shape of enterprise systems like SAP Hybris / commercetools — the same architectural patterns (typed catalog, promotion engine, order management, process orchestration, ImpEx data pipelines) without the licensing. It's a multi-module Spring Boot 4 / Java 21 backend, a Next.js storefront, a React 19 admin console, and a stateless Python AI sidecar, all designed to run stateless and deploy anywhere.

Next.js storefront+React admin Spring Boot backend Payment SPISearch + AI PostgreSQLOpenSearch

Highlights

The parts worth showing

A dozen real subsystems. These are the ones that make people lean in.

Search + AI

Natural-language product search

A shopper types "warm jacket under $50"; a stateless LLM sidecar turns it into a grounded, structured query over an OpenSearch index (keyword + vector hybrid). Fail-open by design — an AI outage degrades search, never blocks checkout.

Backoffice

Visual query builder with joins

A Hybris-FlexSearch-style tool: build queries against any entity — including explicit joins across entities and mass-edit — with every value parameter-bound and a sensitive-field/type blocklist. Round-trips to CSV that ImpEx reads straight back.

Orchestration

Business-process engine

Order fulfilment, consignment, and delivery run as XML-defined processes with wait/branch/loop nodes, cluster locks, and a live flow-diagram in the admin showing exactly where each instance is — with Replay/Restart/Signal controls.

Pricing

Promotion engine

Eight action types — %, fixed, BOGO, bundles, tiered ladders, fixed-price groups — with conditions, vouchers, per-customer caps, and proportional per-line attribution. Money is server-computed and clamped; caps use atomic reservations.

Auth

OAuth2 + RS256 / JWKS

Three grants, asymmetric JWTs published at a JWKS endpoint, refresh-token rotation with reuse detection, HttpOnly refresh cookies, per-IP/-client/-user lockouts, and a sandboxed Groovy scripting console.

Data

ImpEx import/export

Enterprise-style bulk data pipeline: templated CSV, dry-run validation, row-level transactional import, reference resolution by business code, soft-delete semantics — one shared column-deriver so exports re-import cleanly.

Payments

Pluggable payment SPI

A provider registry (Mock / Stripe / Razorpay) chosen by config, money in integer minor units, cumulative refund caps, webhook reconciliation, and indeterminate-result handling that never falsely marks a refund done.

Catalog

Typed catalog + inventory

Base/variant product model, staged→online catalog sync, classification attributes, single-warehouse reservation (holds at checkout, decrement at capture, TTL reaper) so concurrent checkouts can't oversell.

Platform

Cron + jobs engine

Scheduled + on-demand jobs with cluster locking, live progress, abort, retry policies, and a scripting-cron path that shares the console's bindings and sandbox.

Engineering rigor

Built like production, audited like an adversary

The part that separates a portfolio project from a platform: I run adversarial reviews on my own code — and act on what they find.

  • 6-lane adversarial security & architecture audit — found and fixed real issues: a storefront order-code enumeration oracle, optimistic-lock lost updates weakening a brute-force lockout, an unbounded discount overshoot.
  • 597 backend tests, run on real PostgreSQL via Docker with Flyway + schema validate — dev/prod parity that catches drift before prod.
  • Concurrency discipline — pessimistic lock-then-refresh, atomic conditional-UPDATE counters, optimistic @Version; no silent lost updates on money paths.
  • "Server computes money" — client amounts never trusted; entity-level invariants enforce money/config rules even through the generic CRUD path.
  • Fail-open architecture — search and AI degrade gracefully; nothing external can block an order.

What it is — and isn't (the honest part)

This is a solo reference platform, engineered to production patterns, not a system battle-tested at scale.

Deliberate scope today: single-tenant per deployment (with seller-level row isolation), no live payment-gateway round-trip test yet, no automated frontend test suite.

I know exactly where the gaps are because I audit for them — which is the point. Knowing your system's edges is the senior skill.

Under the hood

Stack

Java 21 · Spring Boot 4 PostgreSQL · Flyway OpenSearch 2.17 · vector + keyword Python · FastAPI · LiteLLM React 19 · Vite · MUI Next.js Docker · OCI · cloud-agnostic OAuth2 · RS256 · JWKS Maven multi-module Micrometer · Prometheus · JSON logs