Designing System Architecture for Small‑Medium Companies: When Do You Really Need 5,000 QPS?

The author shares observations from interviewing many companies: large firms tend to ask deep design questions, while small firms often focus on whether they need to support a specific QPS, which can lead to over‑engineering.

Stage 1 – Daily Active Users: a few thousand to tens of thousands

When traffic is low, the priority is survival. A monolithic architecture is recommended for rapid development and deployment. Choose a language the team knows best (Java, Go, Node.js, Python, etc.). Use a single cloud RDS instance (MySQL/PostgreSQL) and a single Redis instance or even local in‑process caches such as Caffeine or Guava. Avoid micro‑services and distributed transactions, which can overwhelm a small backend team.

Note: Do not adopt Kubernetes; use Docker images or lightweight cloud deployment tools, and avoid writing excessive decoupling code for imagined future scalability.

Stage 2 – Daily Active Users: 100 k to 1 M

Business stabilizes and traffic growth reveals performance bottlenecks in single‑machine components (e.g., payment or core order modules). Architecture upgrades and essential monitoring/operations become necessary.

Application layer: vertical split (separate front‑end business from back‑office management, core from non‑core) to prevent large tables in the back‑end from dragging the front‑end down.

Database: enable master‑slave (read/write separation) and add indexes to core tables, solving about 80 % of database performance issues.

Cache layer: introduce a Redis cluster or master‑slave setup; cache hot data to protect the database from concurrent overload.

Asynchronous processing: add a message queue (RocketMQ, Kafka, or lightweight Redis Stream) to smooth peaks, offload time‑consuming tasks such as SMS sending and log collection.

Note: Essential OPS (CICD, monitoring) must be in place to keep up with business growth.

开始引入轻量级的 CICD（如 GitLab CI/Jenkins）和基础的监控（如 Prometheus + Grafana 或云厂商自带监控）

Stage 3 – Daily Active Users: over 1 M or high‑concurrency scenarios

Data volume reaches tens of millions or hundreds of millions, with localized extreme concurrency (e.g., flash sales, large‑scale behavior log analysis, dynamic rule engine computation).

Partial micro‑services: isolate high‑concurrency, high‑change core modules (user center, order, high‑frequency rule engine) as independent micro‑services.

Data layer breakthroughs: consider sharding or introduce BigData components such as Apache Flink for real‑time stream processing and dynamic rule analysis.

Resilience: implement three safeguards – rate limiting, degradation, and circuit breaking – preferring to show “system busy” to some users rather than a full server crash.

Note: Small‑to‑medium companies should not develop complex middleware themselves; instead, adopt mature open‑source or cloud‑provider PaaS solutions (e.g., managed message queues and distributed databases) to save manpower and cost.

Key Takeaways for Small‑Medium Company Architecture

1. Use additional hardware (high‑spec servers) for problems that can be solved by scaling machines, not by redesigning architecture.
2. Choose technology based on the team’s expertise, not on what big‑tech giants use.
3. The best architecture is “just right”: it meets current business needs and can support growth for the next 6‑12 months.