Is There a One‑Size‑Fits‑All Backend Architecture? Exploring Minimalist Solutions

Enterprise software architecture is constantly evolving, especially on the backend side, and each company has its own business model, tech stack, and technical capabilities, resulting in a wide variety of solutions.

There is no "best" architecture, only the one that best fits the current needs, and no perfect architecture, only one that can be continuously iterated.

Two evaluation criteria:

Applicable to the majority of business scenarios (over 70%).

Minimizes total cost, including hardware, software, learning, implementation, and operation expenses.

1. Minimal "universal" architecture

MySQL + Redis + Elasticsearch (the three‑piece stack)

This combination can satisfy 70‑80% of enterprise application scenarios, regardless of the programming language (PHP, C#, Java, Go, Python, Ruby, etc.).

MySQL is open‑source, stable, easy to install, with low entry and operation costs.

Redis is open‑source, high‑performance, and also low‑cost to integrate; it can serve as a distributed lock or cache for hot data.

Elasticsearch is open‑source, high‑performance, and reliable; it excels at fast queries on massive datasets, though it requires more powerful hardware.

The three‑piece stack is simple, efficient, and sufficient for most workloads up to tens of thousands of QPS.

Limitations: horizontal scaling, high availability, and handling traffic beyond ten thousand QPS.

2. Extended minimal architecture (adding Nginx)

MySQL + Redis + Elasticsearch + Nginx (clustered version) introduces Nginx as a reverse proxy, enabling horizontal scaling of application services and high‑availability via virtual IP clustering.

Both Redis and Elasticsearch can be deployed in multi‑node clusters, further improving reliability.

MySQL can use a primary‑replica cluster (one master, multiple slaves) for simplicity while still supporting read‑heavy workloads.

Recommendation: Use the four‑component clustered stack for higher concurrency (up to 100k QPS) while keeping the architecture simple.

3. Multi‑read/write solutions

3.1 MySQL master‑master deployment

Provides write redundancy but increases deployment and maintenance complexity; careful handling of bidirectional replication is required.

3.2 Sharding (MyCat, ShardingJDBC)

Distributes data across multiple databases to improve read/write performance, but adds complexity to application logic and data operations.

3.3 Middleware buffering (MQ + Sentinel)

Introduce message queues (RabbitMQ, RocketMQ) for asynchronous processing and flow control, and Sentinel for rate limiting and circuit breaking, enhancing stability under high load.

3.4 NoSQL replacement (TiDB)

TiDB is an open‑source, distributed SQL database compatible with MySQL syntax, offering horizontal scalability and high write throughput (≈20k TPS). It requires minimal code changes and can handle million‑level QPS.

In a real case, a system generating ~40 billion incremental records daily and peaking at 700k QPS was successfully migrated to TiDB, proving its reliability.

4. Microservice minimal architecture

Under Spring Cloud, a lightweight stack includes Eureka (or Nacos) for service registration, Gateway, Redis, MySQL, and a message queue.

Diagrammatic representations (images) illustrate the simple Spring Cloud layer and the company’s existing microservice setup.

While the company is exploring cloud‑native solutions, the current architecture remains stable.

Conclusion

There is no universal “golden” architecture; choose the simplest, most cost‑effective solution that fits the business scenario.

The so‑called universal architecture is conditional on workload size and technical constraints.

For most cases, Spring Cloud‑based microservices provide a low‑cost, reliable design.