The aim through these system design pieces is to help the reader develop a solid grounding in applying concepts to real projects.
One of the core requirements in System Design is translating business requirements. The way to understand the requirements is to ask questions. What are the core features? How many users do we expect? These are what lead us to the two categories:
- Functional Requirements - Describe what the system should do, and
- Non-Functional Requirements - Describe how the system should perform.
the system must... vs. the system shall...(performance, reliability, scalability, security)
Exercise: Design a mobile banking app that allows users to manage a single bank account.
Questions
- What types of transactions should the application support?
- How far back does transaction history need to go?
- What level of detail do the transactions need to have?
- What level of security does the app need to have?
- Is there compliance we need to adhere to?
- What are the performance requirements?
- How do we display transaction status?
Functional Requirements
- Users should be able to login to their account using username and password.
- Users should be able to export transaction data from past 12 months.
- Users required to set up MFA.
- All datetime should be localized.
- Can't send money if the balance is zero.
- Currency supported is KES.
- Transactions should display datetime, amount, status.
- Search and filter history.
- Users should be able to transfer and receive money.
Functional requirements define the features to have in the application. They are gathered through interviews with the relevant stakeholders and users as well as brainstorming workshops.
To understand non-functional requirements, we need to understand the CAP Theorem.
CAP Theorem
The CAP theorem states that only two of the three desirable characteristics; consistency, availability and partition tolerance can be shared or present in a networked shared-data system or distributed system.
- C = Consistency = How well does the system ensure that all users see the same data at the same time.
- A = Availability = Proportion of time a system is operational and accessible.
- P = Partition tolerance = Continues to operate despite arbitrary message loss or failure in parts of the system.
In addition to these, we also think about reliability (ability of the system to function correctly over time) and resiliency (how well a system handles failures.) when it omes to system quality.
Proof of CAP Theorem
A distributed system with Server 1 and Server 2. The two servers cannot communicate; the system is partition tolerant. So we prove that it can either be consistent or available.
Suppose that there's a network failure i.e S1 and S2 cannot communicate. Assume that the client makes a write to S1. Then client makes a write to S2. Given S1 and S2 cannot communicate, they have different views of the data. If the system has to remain consistent (ensure it is showing the same data) then it must deny the request thus give up on availability. If the system is available, then it has to give up on consistency. Proving the CAP theorem.
The theorem assumes that failures are inevitable and we therefore have to decide what is more important, to have the latest data or always be available. This helps to think about tradeoffs involved in designing and building a system. It also helps us explain why certain types of systems may be more appropriate for certain use cases. For example, a banking application will favour consistency over availability since the aim is to ensure that the users see the same transaction data at any given time. On a social media application, availability is preferred as the data can always become eventually consistent but the system needs to stay accessible.
System Quality
- Reliability (Availability , Resilience , Consistency)
- Observability - The ability to know whats happening in our system. It is critical for effective troubleshooting as it provides insight into what's happening when something goes wrong. Poor observability means you only discover you're missing logging when an issue occurs whereas good observability includes proper logging, metrics, and alerting systems to quickly triage issues.
- Security - The ability to safeguard a system and its data.The Chesterton's fence is a mental model of intellectual humility. It states that one should not remove or alter an existing system or rule until they understand the reason it was originally established. In security, especially when dealing with systems that were pioneered before you, it is best to understand why things work the way they do before making an irreparable mistake.
- Scalability - Handling increases and decreases in system usage. Designing systems that can scale both up and down is important because of cost efficiency and resource management. If you run an ecommerce application, running it at full capacity at all times may be expensive and wasteful since you may be experiencing seasonality. The traffic may be higher than ever during Black Friday and lowest in January. Cloud computing enables systems to scale up during those high-traffic periods and down during the quieter times, optimizing resources and costs.
- Adaptability - Handle changing requirements or user behaviours.
- Performance
- Latency - How quickly the system responds (to a request).
- Throughput - How much data can move through the system at a time. Latency is more important for applications like shopping carts where users expect immediate fedback and may abandon slow-loading pages meaning you lose money. Throughput is more important for applications handling large amounts of datalike video streaming in Netflix.
Non-functional
Non-functional requirements help determine which aspects of system quality are most important for a given system by answering questions about expected users, response times, and other quality metrics. These help understand traffic patterns and request volumes inorder to properly scale the system to handle the actual load rather than ust focusing on user numbers.
Exercise: Design a mobile banking app that allows users to manage a single bank account.
Questions
- How many transactions per user?
- How frequent are the transactions?
- How long do we store transaction data.
- What is the minimum latency for a transcation?
- What is the availability target?
- How consistent are the traffic patterns?
- How frequently do we backup data?
- How long should it take to restore data?
- Is there data compliance to be aware of?
- What are the audit requirements?
Non-functional Requirements
- The system should have 4 9s (four nines) of availability.
- Transactions should be backed up daily.
- Transaction data must be encrypted in transit and at rest.
- Every transaction and user action must be audited.
- Data processing compliance and PII.
Non-functional requirements are gathered through benchmarks with IT teams to set performance expectations, consulting security experts for data protection, and usability tests.
After requirements, we can now identify what entities we are working with and come up with a model for the system.