Stop Memorizing Isolated Terms: Visualize a User Request Flow in a Microservice Architecture

Overview

The author connects six days of architecture concepts—CAP, BASE, 2PC, TCC, Saga, microservices, service governance, Redis, cache avalanche, Kafka, and message queues—into a single system diagram that shows how a user request traverses the system.

01 First Stop: API Gateway

External requests first hit the API gateway, which serves as the unified entry point for the microservice system. It performs routing, authentication, authorization, rate‑limiting, and request aggregation. For a "create order" request, the gateway decides which service should handle it and checks login status, permissions, and current traffic limits.

02 Second Stop: Load Balancing

After the gateway, the request is distributed among multiple instances of the order service (e.g., Order‑A, Order‑B, Order‑C). Load‑balancing strategies such as round‑robin, weighted round‑robin, least‑connections, IP hash, or consistent hash ensure no single instance is overloaded.

03 Third Stop: Order Service

Validate user

Create order

Query product information

Check inventory

Write order data

Emit order event

The service focuses solely on order‑related business, delegating inventory, payment, logistics, and points to their respective services, illustrating the business‑capability‑oriented microservice split.

04 Fourth Stop: Service Registry

When the order service needs to call the inventory service, it queries a service registry to discover available instances (e.g., 10.0.0.8:8080, 10.0.0.9:8080). Services register themselves at startup and look up targets at call time, providing dynamic service discovery.

05 Fifth Stop: Redis Cache

The order service first checks Redis for product details, categories, or hot items. If the cache hits, the data returns immediately; if it misses, the service reads from the database, writes the result back to Redis, and returns the data. The cache reduces database load, lowers latency, and increases throughput, but introduces three risks:

Cache avalanche – many keys expire simultaneously.

Cache penetration – queries for non‑existent data.

Cache breakdown – a hot key expires.

Mitigations include random expiration times, caching empty values, Bloom filters, and distributed locks.

06 Sixth Stop: Database

The final persistent store is a relational database (e.g., MySQL) where orders, inventory updates, and payment statuses are committed. The author notes that databases often become bottlenecks and previews deeper topics such as B‑Tree, clustering indexes, MVCC, read/write splitting, and sharding.

07 Seventh Stop: Kafka Message Queue

After order creation, non‑critical actions (points, SMS, logging, recommendation updates) are sent as messages to Kafka. Consumers—inventory service, points service, SMS service—process the messages asynchronously, achieving decoupling, peak‑shaving, and eventual consistency. Core Kafka concepts listed: Topic, Partition, Replica, Offset, Consumer Group.

08 CAP / BASE Placement

Every distributed component must consider CAP and BASE trade‑offs. For strongly consistent data (inventory, payment, locks) the author prefers consistency‑first (CP). For eventually consistent features (comments, recommendations, likes) the author leans toward availability‑first (AP) and BASE principles.

09 Distributed Transaction Placement

When multiple services must succeed together, three patterns are available:

2PC – strong consistency, low concurrency.

TCC – reservation‑confirm‑cancel, suitable for resource reservation.

Saga – local transactions with compensating actions, ideal for long‑running workflows.

The author maps each pattern to typical e‑commerce scenarios.

10 Service Governance

Governance spans the whole diagram: API gateway (entry), service registry (discovery), load balancer (routing), rate limiting (traffic control), circuit breaking (downstream failure protection), and degradation (graceful fallback). These rules keep the system reliable during traffic spikes.

11 Putting It All Together

The final diagram (textual representation) shows the request flow: User → API Gateway (routing, auth, rate‑limit) → Load Balancer → Order Service → Redis cache (hit/miss) → Database → Kafka → downstream services (inventory, points, SMS) → MySQL persistence. Side notes annotate CAP/BASE, transaction patterns, microservice boundaries, governance, and cache pitfalls.

12 Exam‑Style Answer Example

A sample answer to a design question summarises the same flow, emphasizing gateway handling, multi‑instance deployment, service discovery, Redis/CDN caching with avalanche/penetration/ breakdown mitigations, asynchronous processing via Kafka, appropriate transaction pattern selection, and protection via circuit breaking, rate limiting, and degradation.

13 Key Takeaways

Remember the concise statements: request enters API gateway; gateway forwards via load balancer; services locate each other through the registry; hot data is cached in Redis; order creation triggers Kafka messages; CAP/BASE guide consistency trade‑offs; 2PC/TCC/Saga resolve cross‑service transactions; and governance mechanisms safeguard the system.

14 Self‑Test Questions

Where does an external request first enter a microservice system?

How do services discover each other's locations?

Who assigns requests when multiple service instances exist?

What are the handling steps for cache hit versus miss?

What problems does Kafka solve in this diagram?

Which transaction pattern matches strong consistency, resource reservation, and long‑process compensation?

What do circuit breaking, rate limiting, and degradation each protect?

Mastering these points completes the first‑week architecture knowledge shelf.