Tech • AI • Robotics • Game
Non-Functional Requirements in System Design Explained
5/10TL;DR
An online shop’s evolution shows how availability, reliability, scalability, fault tolerance, recovery, and maintainability must be defined, measured, and tested as customer demand grows.
KEY POINTS
Availability must reflect real customer outcomes
Availability is not just whether a server is up at a given moment, but whether customers can successfully use the service when needed. For an online shop, a meaningful measure could be the share of valid order requests completed successfully over a month. If 10,000 valid orders are attempted and 9,990 succeed, availability is 99.9%. The definition matters because a homepage may still load while order submission is broken.
Reliability depends on correctness, not only responses
A running application can still produce the wrong outcome. One failure case arises when an order is saved in the database but the confirmation never reaches the browser, prompting the customer to retry and accidentally create a duplicate purchase. A more reliable design gives each submission a unique identifier and enforces a database rule that prevents the same identifier from being stored twice. A repeated request can then return the original order instead of creating a second one.
Scalability requires locating the real bottleneck
During a promotion, product pages slowed and order requests queued as traffic rose. Testing showed the database was coping, but the application server was close to its CPU limit. The team could increase the size of one machine through vertical scaling, or add another application instance through horizontal scaling. It chose horizontal scaling, placing a second instance behind a load balancer, which reduced waiting times under test.
Shared state can undermine scaling gains
Adding instances only works if any instance can serve any request. If a customer’s basket exists only in the memory of one application server, the next request routed to another server can make that basket appear to vanish. That means performance tests must reflect real user actions, not just simple page loads, and the design must support sharing work safely across instances.
Fault tolerance has limits that must be stated clearly
With two application instances running, one was stopped while traffic continued. The load balancer detected the failed instance and stopped routing new requests to it, while the remaining instance continued serving customers because it had enough spare capacity. That is fault tolerance, but only for specific failures. If both instances run on the same machine, one machine failure can remove both; if they share one database, a database outage can still halt ordering.
Detection and failover do not eliminate every failed request
Even when a system tolerates a server failure, some requests may still fail during the transition. Health checks take time, and requests already in progress on the failed instance can be lost. Those failed requests must be counted in the test results. Resilience is therefore measured by customer experience during faults, not just by whether service eventually continues.
Recovery is different from fault tolerance
When the database fails, the shop may stop accepting orders entirely until an operator promotes a standby database and redirects application connections. That is recovery after interruption, not uninterrupted operation. Both patterns are useful, but they produce different service levels and different customer experiences, making acceptable downtime a business decision as much as a technical one.
Maintainability reduces the cost and risk of change
A simple delivery fee update exposed duplicated business logic when one screen showed the new fee and another still used the old one. The fix was to define the delivery rule in one shared location, reuse it across basket and order calculations, add tests for different delivery conditions, and document where the rule belongs. Better maintainability also depends on clear code ownership, useful logs, readable configuration, and deployment steps another team member can follow.
Non-functional requirements turn qualities into testable targets
Before redesigning further, the team needs explicit agreement on what the system must handle and what service level customers require. Those expectations become non-functional requirements, giving engineers concrete targets for availability, performance, fault handling, and ease of change. The system can then be tested against evidence rather than assumptions.
CONCLUSION
As the shop grows, technical quality depends less on a single server staying online and more on whether the whole system delivers correct results under load, failure, and change. Clear targets and realistic tests are what turn those qualities into dependable service.
Ask a question