Reliability
The system works as expected 99.999% of the time
- Performs its function
- Tolerates user mistakes
- Prevents unauthorized use
- Does not break
The application performs the function that the user expected. • It can tolerate the user making mistakes or using the software in unexpected ways. • Its performance is good enough for the required use case, under the expected load and data volume. • The system prevents any unauthorized access and abuse
Termen used for fault-proof systems.
Redundancy, replication, policies. RAID - example of existing protocol
Fault vs. Failure
Fault - happen, but we can work Failure - final, we cannot work
A fault is usually defined as one component of the system deviating from its spec, whereas a failure is when the system as a whole stops providing the required service to the user
Types of faults:
-
software e.g. bugs: OS, 3rd party, yours —handles⇒ testing application
-
hardware —handles⇒ test connectivity, maintenance, backups
Scalability
Adjust to demand, as the system grows.
- Automatically (elastic system)
- Launch/performance (speed)
- Throughput / responsive time (seconds)
- Vertical scaling / Horizontal scaling
In order to discuss scalability, we first need ways of describing load and performance quantitatively.
Load can be described with a few numbers which we call load parameters. The best choice of parameters depends on the architecture of your system: it may be requests per second to a web server, the ratio of reads to writes in a database, the number of simultaneously active users in a chat room, the hit rate on a cache, or something else.
Maintainability
Over time, many different people will work on the system (engineering and oper‐ ations, both maintaining current behavior and adapting the system to new use cases), and they should all be able to work on it productively
design principles for software systems:
Operability
Make it easy for operations teams to keep the system running smoothly.
Simplicity
Make it easy for new engineers to understand the system, by removing as much complexity as possible from the system. (Note this is not the same as simplicity of the user interface.)
Evolvability
Make it easy for engineers to make changes to the system in the future, adapting it for unanticipated use cases as requirements change. Also known as extensibil‐ ity, modifiability, or plasticity