Why Adding Cache First Is the Wrong Move for Slow Systems

01

Performance optimization begins with monitoring, not with caching. The author lists four key metrics: response time (how long a request takes), throughput (requests processed per unit time), concurrency (simultaneous requests or users), and resource utilization (CPU, memory, disk, network, DB connections). The article stresses that exam answers should first describe how these metrics reveal the real bottleneck before proposing any solution.

02

The author groups common optimization techniques into five "axes": cache, async, database optimization, horizontal scaling, and rate‑limiting/degradation.

03

Cache reduces repeated reads of hot data such as product details, categories, hot items, inventory display, user sessions, and configuration data. Typical caches include Redis, local memory, and CDN. Benefits are fewer DB hits, lower response time, and higher throughput. However, caches introduce consistency, avalanche, penetration, and hot‑key issues, so a complete answer must mention expiration policies, warm‑up, rate‑limiting, and Bloom filters.

04

Async shortens the main request path by moving non‑essential, time‑consuming tasks (e.g., inventory deduction, point addition, SMS sending, logging, third‑party notifications) to a message queue. The main flow keeps only order creation and immediate response. Suitable async tasks include sending SMS/email, adding points, logging, report generation, and third‑party notifications, while critical operations like payment confirmation must remain synchronous.

05

Database optimization often targets the database layer. Measures are building indexes, rewriting SQL to avoid full scans, read‑write splitting, sharding (分库分表), and connection pooling. Indexes prevent full table scans; SQL tuning removes unnecessary joins and SELECT *. Read‑write splitting offloads reads to replicas; sharding splits large tables by business or user dimensions; connection pools reuse connections to cut overhead. The article warns that sharding is a heavy‑handed technique and should follow indexing and SQL tuning.

06

Horizontal scaling addresses limited capacity of a single server. Deploying multiple stateless service instances behind a load balancer spreads traffic, increasing throughput and availability. The author distinguishes vertical scaling (adding CPU, memory, disk) from horizontal scaling (adding machines). Stateless design is emphasized because it allows any request to be routed to any instance, simplifying scaling and failover.

07

Rate‑limiting and degradation protect the system under traffic spikes. Rate‑limiting caps the number of requests per time window, queuing or rejecting excess traffic. Degradation disables or simplifies non‑core features (e.g., recommendations, comments, points) during high load, ensuring core functions like browsing, ordering, and payment remain available.

08

For a typical exam scenario—massive traffic during a promotion causing slow product pages and order APIs—the recommended answer follows the five‑step structure: 1) monitor metrics to locate the bottleneck; 2) cache read‑heavy data with Redis or CDN; 3) deploy multiple order‑service instances with load balancing; 4) async non‑core tasks via Kafka; 5) add indexes, optimize slow SQL, and use read‑write splitting; 6) shard large tables if needed; 7) apply rate‑limiting to the order API; 8) degrade non‑essential features; 9) set up continuous monitoring and alerts.

09

The article warns against listing tools without context. Instead of "use Redis, Kafka, load balancer, sharding", a good answer ties each measure to a specific problem, describes the effect, and shows a coherent architecture.

Self‑test

Why can’t you start performance tuning by adding cache? Because you must first locate the real bottleneck, which could be CPU, network, lock contention, or external services.

What is response time? The elapsed time from request issuance to response receipt.

What is throughput? The number of requests the system can handle per unit time.

What is concurrency? The number of simultaneous requests or active users.

What problem does cache solve? It reduces repeated access to hot data, lowering response time and increasing throughput.

Why does a message queue improve performance? It moves non‑core, time‑consuming tasks to asynchronous processing, shortening the main path and smoothing traffic spikes.

What are common database‑level optimizations? Indexes, SQL tuning, read‑write separation, sharding, and connection pooling.

What is horizontal scaling? Adding more machines or service instances and using load balancing to distribute load.

Why design services as stateless? Stateless services are easier to scale horizontally and to perform failover because any instance can handle any request.

What’s the difference between rate‑limiting and degradation? Rate‑limiting controls incoming request volume; degradation disables or simplifies non‑core functionality to protect core paths.

Finally, the author summarizes the five key takeaways: cache to cut DB hits, async to offload non‑core work, DB tuning (indexes, SQL, read‑write split, sharding, pool), horizontal scaling with load balancer, and rate‑limiting/degradation to protect core functions. The overarching principle is: locate the bottleneck first, then select the appropriate technique.