How to Write Score‑Winning Answers for Architecture Case Questions

The author discovered a pitfall in software‑exam case questions: knowing many technical terms does not guarantee points unless the answer clearly ties those terms to the business problem.

01

Case questions test design thinking rather than memorization. They ask how you would design a system with a problem, improve an existing flawed system, evaluate pros and cons of a solution, or ensure a quality attribute.

Typical signals in the stem include traffic spikes, slow responses, database pressure, service outages, data inconsistency, tight coupling, deployment difficulty, and scaling challenges. Recognizing these keywords helps map them to solution templates.

02

Step 1 – Identify the problems. Do not answer immediately; first highlight pain points such as rapid traffic growth, slow product‑detail pages, high CPU on the database, long order‑creation chains, or single‑point failures.

These translate to architectural issues: high concurrency, latency, database bottleneck, long synchronous chains, and single‑point failure.

03

Step 2 – Choose the pattern. Different issues correspond to different templates:

Latency or DB pressure → performance optimization.

System downtime or single‑point failure → high availability.

Order‑inventory inconsistency or payment status lag → distributed transactions and eventual consistency.

Heavy coupling, release difficulty, scaling trouble → micro‑service decomposition.

Traffic bursts, flash sales → rate‑limiting, caching, message queues, spike‑shaving.

The key is to map stem signals to architectural “routines”.

04

Step 3 – Tie the solution to the scenario. Instead of writing “use cache”, specify the business object and effect, e.g., “Use Redis or CDN to cache product‑detail, category, and hot‑item data, reducing database reads and improving response time.”

Similarly, replace “use message queue” with “asynchronously handle SMS notifications, point accrual, and logging via a message queue to shorten the order‑creation critical path.”

Structure each answer as: technology + business object + impact.

05

The author proposes a universal sentence pattern: “For the xxx problem, adopt the xxx solution, used for xxx, thereby xxx.” Examples illustrate applying this pattern to caching and asynchronous processing.

06

Template 1 – High concurrency / performance optimization.

Signals: traffic surge, slow response, DB pressure, insufficient throughput, flash sales.

Answer directions include Redis/CDN caching for hot data, async processing via message queues, horizontal scaling with load‑balanced stateless instances, SQL/index tuning, read‑write splitting, sharding, rate‑limiting for spike interfaces, degrading non‑core features, and monitoring key metrics.

Exam tip: always mention rate‑limiting for high‑concurrency and start with bottleneck identification via monitoring.

07

Template 2 – High availability / disaster recovery.

Signals: single‑point failure, server crash, DB failure, system downtime, continuous business requirement, geographic redundancy.

Answer directions cover multi‑instance deployment with load balancing, clustering critical components (service registry, config center, Redis, Kafka), master‑slave DB replication with failover, health checks, fault detection, traffic switchover, graceful degradation, and RTO/RPO definitions.

08

Template 3 – Data consistency / distributed transactions.

Signals: order‑inventory mismatch, payment status lag, concurrent data modifications, cross‑service transactions.

Answer directions discuss using local transactions or 2PC for strong consistency, TCC for cross‑service flows, Saga for long‑running processes, reliable messaging with retries and idempotence, and compensation mechanisms.

09

Template 4 – Caching issues.

Signals: hot‑data traffic, cache miss pressure, cache penetration, massive key expiry, cache‑DB inconsistency.

Answer directions include caching hot data, setting randomised TTLs to avoid cache avalanche, caching nulls or using Bloom filters to prevent penetration, mutex/logic expiration for cache breakdown, write‑through or delayed double‑delete for consistency, and monitoring/pre‑warming hot keys.

10

Template 5 – Microservice decomposition / service governance.

Signals: monolithic size, tight coupling, release difficulty, scaling difficulty, team collaboration issues, complex service calls.

Answer directions involve splitting by business capability, independent development/deployment, service registry, API gateway for routing and security, load‑balanced calls with circuit‑breaker and retries, observability via tracing and logging, and eventual consistency via reliable messaging.

Risk note: over‑splitting increases communication overhead, distributed transaction complexity, and operational burden.

11

Example: e‑commerce flash‑sale scenario.

Problems identified: traffic surge (high concurrency), slow product page (cache), slow order path (async), DB CPU high (bottleneck), synchronous inventory/points/SMS (async), server crash (single‑point failure).

Solution steps:

Cache product‑detail, category, hot items with Redis/CDN.

Make order service stateless, deploy multiple instances behind load balancer.

Offload SMS, points, notifications to a message queue.

Optimize SQL, add indexes, use read‑write splitting, consider sharding.

Rate‑limit flash‑sale interfaces.

Degrade non‑core features during peak.

Cluster key components (order service, Redis, Kafka, registry) for redundancy.

Set up monitoring and alerts on latency, throughput, concurrency, resource usage.

This answer is concise, scenario‑specific, and scores well.

Self‑test

Why can’t you just write “use cache”? – It’s too vague; you must specify the business object and the problem it solves.

What measures correspond to “traffic surge, slow response, DB pressure”? – Cache, async processing, DB optimization, horizontal scaling, rate‑limiting, degradation, monitoring.

What does a server crash indicating? – Single‑point failure; solve with multi‑instance, load balancing, fault detection, failover.

What does “payment succeeded but order status not updated” imply? – Distributed transaction or eventual consistency; use reliable messaging, retries, compensation, idempotence, reconciliation.

Standard sentence pattern? – “For xxx problem, adopt xxx solution, used for xxx, thereby xxx.”

Risk to mention for microservice splitting? – Over‑splitting adds communication, distributed‑transaction, ops, and monitoring complexity.

Key takeaway: case questions require “technology + business object + impact”, not just a list of buzzwords.