System Design · Feb 2026 — Apr 2026

BookStore

BookStore is a set of independently deployable Spring Boot services behind an API gateway. Identity is JWT. Request-time reads that must complete before an order is accepted go over OpenFeign. Everything that can happen after an order is accepted — payment, notification, analytics — is an event on Kafka.

JavaSpring BootMicroservicesKafkaMySQLAWSKubernetesReact

Problem

Auth, catalog, users, orders, payments, notifications, and analytics cannot share one release cycle or one failure domain. Putting Stripe or email on the checkout HTTP thread makes the store as slow as its slowest dependency.

Solution

Split the platform by write-path ownership. The gateway is the only public edge. Auth issues tokens. Book and User serve consistent reads. Order accepts the write and publishes OrderCreated. Payment, Notification, and Analytics consume independently.

Spatial architecture

Inspect the live graph

The same BookStore chassis as the homepage. Click a service, drag to orbit, and read purpose, APIs, and events in the inspector.

Click a node · drag to rotate · Esc to clear

Interactive architecture

Explore the full topology

Book Service, MySQL, AWS, and Kubernetes sit on this map. Click a node or play a flow to see how a request or event actually moves.

Choose a flow to watch the path move through the architecture.

sync · order

Order Service

Order creation and lifecycle — the write that starts the rest of the system.

Why it exists

Checkout must return once the order is accepted. Payment, mail, and analytics are not required for that HTTP response.

Responsible for

Create and manage order lifecycle.
Publish OrderCreated after accept so consumers are not on the request thread.

Technology

Spring Boot
MySQL
Kafka
OpenFeign

Important APIs

Order create and status through the gateway.
OpenFeign to User when a consistent profile read is required.

Database

MySQL — orders

Kafka topics / events

OrderCreated

Incoming

API Gateway

Outgoing

User (OpenFeign)
Kafka
MySQL

Design decisions

HTTP confirms accept. Stripe and notifications are not chained on that call.
OrderCreated is the domain event contract for payment, notification, and analytics.

Click a node · play a flow · Esc to clearSolid · request / eventKafkaDashed · runtime

Engineering Lab

The mechanics, not the metaphor.

Small simulations of the same ideas used in this platform — Kafka partitions, an order fan-out, the AWS shape, and why checkout stays off Stripe.

Partitioning, consumer groups, parallel consumption, and offsets — with records you can step through.

Consumers

Producer

Each record has a key. Partition = hash(key) % 4. Same key always lands on the same partition, preserving per-key order.

Topic · 4 partitions

P0off 0

P1off 0

P2off 0

P3off 0

Consumer group · 2

One group shares the topic. Each partition is assigned to a single consumer in the group — that is parallel consumption without breaking partition order.

partitions P0, P2

partitions P1, P3

System Overview

BookStore is an e-commerce platform split into services so catalog reads, identity, checkout, and post-order work do not share a process. The React client talks only to the gateway.

JWT at the edge; services do not invent a second login.
OpenFeign for the few synchronous reads Order cannot skip.
Kafka for everything that can happen after accept.
Docker first; AWS and Kubernetes are the designed runtime, not a published cluster dump.

Architecture

The topology is edge → synchronous domain services → event bus → asynchronous consumers. MySQL sits under the services that own rows. Infrastructure is drawn below the application plane so it is not confused with a domain API.

Gateway → Auth, User, Book, Order.
Order → Kafka → Payment, Notification, Analytics.
Each stateful service owns a MySQL schema.

Microservices

Boundaries follow write ownership. Auth owns credentials. User owns profile. Book owns catalog. Order owns the order row and the OrderCreated contract. Payment, Notification, and Analytics do not write that row.

Request Flows

Four paths matter in production: authenticate, browse, accept an order, charge it. Browse never waits on Kafka. Checkout never waits on Stripe.

Kafka / Event-Driven Architecture

OrderCreated is the documented domain event. Payment, Notification, and Analytics each use their own consumer group so they can retry, lag, or fail without sharing a thread or a lock.

Producer: Order Service.
Event: OrderCreated.
Consumers: Payment, Notification, Analytics — independent groups.
Partitioning preserves per-key order; it does not make analytics transactional with checkout.

Database Design

MySQL is the system of record. There is no shared database across Auth and Order. Catalog lives with Book. Analytics is fed from events, not from joining checkout tables on the request path.

Auth / User / Book / Order / Payment: MySQL per service.
Notification does not own order records.
Analytics is eventually consistent by design.

Authentication & Security

Spring Security issues JWT. The gateway is the authenticated surface. Stripe stays inside Payment. Service-to-service reads that must be consistent use OpenFeign, not a public token on an internal URL.

AWS Infrastructure

The platform is designed as a cloud-ready AWS deployment: containerized services, Kafka, MySQL. This page does not invent an EKS/EC2/RDS inventory that was not published with the project.

Docker images as the unit of deploy.
AWS as the destination for compute and data.
Stripe remains an external provider, not an AWS service on the checkout thread.

Kubernetes / Deployment

Independent services are the reason Kubernetes is in the design. Auth can roll without Order. The gallery presents that as the intended control plane — not as a claim that a named EKS cluster is in production.

One service, one deployable.
Gateway remains the only public ingress.
Designed for replica-level scale of the hot read and write paths.

Observability

The design keeps side effects off the request so you can see which hop failed. Order HTTP succeeding while Payment lags is visible as consumer lag, not as a 502 on checkout. Metrics and structured logs watch that lag — they do not pull Stripe back onto the checkout thread.

Scalability

Stateless JWT lets Auth add replicas. Book is a read path and can scale without scaling Payment. Kafka lets Payment, Notification, and Analytics scale as separate consumer groups. Order scales with accept throughput, not with Stripe.

Failure Handling

If Stripe is slow, checkout still returns — Payment retries from the log. If Notification is down, Payment still processes. If Auth is down, browse of public catalog can still be reasoned about separately from checkout. The log is the backlog, not an in-memory queue on Order.

Design Decisions

The decisions that matter are few and they are enforced by the topology.

One gateway.
JWT, not sessions.
OpenFeign only when accept cannot proceed without a consistent read.
OrderCreated as the async contract.
Database per service.
Docker first; AWS/Kubernetes as the designed runtime.

Trade-offs

Eventual consistency on payment and notification is the cost of a fast accept. Operators must watch consumer lag. OpenFeign to User couples Order availability to User at accept time — that is intentional. A shared database would have been simpler to query and harder to deploy.

Accept is fast; payment status is not on that response.
More moving parts than a modular monolith.
Catalog is consistent on read; analytics is not.

All system designs Back to portfolio