Tech • AI • Robotics • Game
What Is System Design?
3/10TL;DR
A simple online ordering system worked at first, but heavier promotional traffic exposed CPU limits on the application server, leading the team to redesign for scalability, resilience, recovery, and access control.
KEY POINTS
Initial architecture
The shop’s first online ordering setup used a straightforward three-part design: a customer-facing website, an application running on one server, and a database on another server. Customers could browse products, choose quantities, and submit orders, while staff could view incoming orders and prepare them.
Core order flow
When an order was submitted, the application validated the request, stored the order in the database, and returned a confirmation. Early testing showed that products loaded correctly, orders were saved properly, and staff could access the records they needed.
Traffic surge exposed a bottleneck
The system performed well for several weeks until a promotion drove a larger number of simultaneous visitors. Product pages became slower, and some customers received errors when trying to place orders, even though the application’s features had not changed.
Diagnosis pointed to the application tier
Investigation showed that the database was still keeping up, while the application server’s CPU was running close to full utilization. Reproducing the issue under a similar traffic test gave the team a clear target for improvement.
Scaling out with a load balancer
Rather than relying on a single stronger server, the team added a second application server and placed a load balancer in front of both instances. That allowed customers to keep using one address while incoming requests were distributed across the two application copies.
State handling became a design issue
Adding a second server required checking that either server could handle any request. If information needed for the next request existed only on one server, sending the customer to the other could break the process, so the application had to be adjusted to avoid server-specific dependency.
Performance improved, but complexity rose
After the redesign, repeated traffic tests showed faster responses and fewer failed requests under the same workload. The gains came with extra cost and operational effort, including another server to pay for, a load balancer to configure, and more infrastructure to monitor.
Single-server failure no longer meant total outage
When one application server later stopped working, the load balancer’s health checks detected the problem and stopped sending new requests to it. The remaining server continued handling traffic, though any requests already in progress on the failed server could still be lost and the surviving server still needed enough spare capacity.
The database remained a critical dependency
Even with multiple application servers, the database was still a single point on which order placement depended. If it became unavailable, neither application server could save new orders, which shifted attention from scaling to recovery planning.
Recovery goals shaped the database strategy
The team discussed two business questions with the shop owner: how long ordering could be interrupted and how much recently saved data could be lost. Those answers determined whether backups alone were enough or whether a standby database was needed for faster failover with different trade-offs in cost, complexity, and data guarantees.
Security required more than a working interface
Access control emerged as another core design concern. Customers should only be able to see their own orders, while staff should only access the orders relevant to their work, and those checks must be enforced by the application itself rather than by simply hiding website buttons.
System design tied the decisions together
The changes illustrate system design as the process of deciding which components are needed, what each one does, how they communicate, where data lives, how the system handles demand, how it recovers from failure, and how access is controlled. The lesson was not only how to fix a slowdown, but how to align technical choices with business needs before problems appear in production.
CONCLUSION
The shop’s ordering platform evolved from a simple working release into a system shaped by performance limits, failure scenarios, and security requirements. The central challenge was balancing reliability and scale against the added cost and complexity needed to support the business during peak demand.
Ask a question