A Ready‑to‑Use Template for Scoring High on the System Architecture Designer Exam

The template guides candidates to quickly produce a high‑scoring system architecture design paper by replacing placeholder sections with their own project details while preserving the prescribed structure.

Project Overview : The example project is an "Intelligent Sports Venue Management System" aimed at solving low operational efficiency, high costs, and venue idle rates caused by manual processes such as promotion, booking, lighting control, settlement, and monitoring.

Key Challenges identified include (1) performance bottlenecks during peak traffic (e.g., 8 million QPS and 8 s average response time during a 2023 Double‑11 promotion, leading to a 15% order‑timeout rate), (2) insufficient availability (99.5% SLA, 43 h annual downtime), and (3) poor scalability (codebase >2 million lines, feature‑to‑production cycle of 2 weeks).

Architecture Goals were set to achieve peak QPS/TPS targets, keep P99 response time ≤200 ms, raise SLA to 99.99% with ≤52 min annual downtime, enable horizontal scaling within 5 min, and meet Level‑2 security compliance with full‑chain data encryption.

Design & Practice (ABSD) follows a six‑step process: Requirements, Design, Documentation, Review, Implementation, and Evolution. After six months of development, quantitative results show availability improving from 99.5% to 99.99% and downtime dropping from 43 h to 52 min.

Solution Selection compared (1) optimizing the existing monolith—low cost but unable to break the inherent scalability ceiling—and (2) adopting a microservice architecture. The latter was chosen, splitting the system into independent services (e.g., user, product, order, inventory, payment, marketing) using Spring Cloud Alibaba + Kubernetes.

Core Technical Practices include:

Domain‑Driven Design to define bounded contexts and service boundaries.

Service registration and configuration via Nacos.

Circuit breaking and rate limiting with Sentinel (three‑level strategy, 50% error‑rate trigger, 10 s window, 10% probe traffic).

Distributed transaction handling with Seata.

Feign + Ribbon for synchronous load‑balanced calls and Kafka for asynchronous decoupling.

High‑availability stack: Nginx + LVS + Keepalived for four‑layer load balancing (VIP failover <3 s); MySQL master‑slave with MHA (RTO < 30 s, RPO = 0); Redis Sentinel for automatic failover (<30 s).

Results :

System split into 32 microservices, reducing code size from 2 million lines to 60 k lines.

Feature delivery cycle shortened from 2 weeks to 2 days (400% productivity gain).

Peak throughput increased from 2 000 TPS to 15 000 TPS.

Response time reduced from 800 ms to 120 ms (85% improvement).

Availability rose to 99.99% with downtime limited to 52 min even under simulated total downstream service failure.

Conclusion & Reflections :

The microservice migration successfully addressed the core problems of performance, availability, and scalability.

Over‑granular service splitting initially increased operational complexity; later consolidation to 32 services highlighted the need to align service boundaries with business domains.

Future work includes introducing a Service Mesh (Istio) for zero‑intrusion traffic management.

The template emphasizes that by following the ABSD methodology and leveraging the described technologies, candidates can produce a well‑structured, data‑driven architecture paper that meets exam scoring criteria.