System Design Learning

docx

School

Western Governors University *

*We aren’t endorsed by this school

Course

C259

Subject

Information Systems

Date

Jan 9, 2024

Type

docx

Pages

Uploaded by CoachSnake4721

System Design Learning Functional Requirements What problem does it solve?  Address the core issue users are facing.  The main problem helps in defining features and non- functional requirements. Example:  Problem: Users want to be more productive with their daily tasks.  Solution:  Features: Maintain a simple list of tasks and their due dates.  Non-functional requirements: Ensure low latency. How to Identify Essential Features? 1. Core Features:  The absolute necessary features to address the user's problem.  Todo's Example:  Create tasks  Modify tasks  Mark tasks as completed

2. Support Features:  Features that provide convenience to users.  Todo's Example:  Display a list of tasks  Assign due dates to tasks Three Important Questions for System Design 1. Is the system "read" or "write" heavy?  Most systems tend to be read-heavy. Impact on Architecture:  Design Requirements: 1. Scale the database 2. Ensure redundancy of services 3. Implement effective caching  System Attribute Priorities: 1. Read-heavy systems should prioritize reading over writing. 2. Monolithic or Distributed Architecture?  Monolithic: All components reside on a single server.  Distributed: Components are independent and hosted on separate servers; no shared hardware.

How to Choose the Right Architecture? - For large-scale services (e.g., Netflix, YouTube): opt for a distributed architecture. - For smaller-scale, hypothetical services (e.g., "parking lot", "caching machine"): A single server might suffice. 3. Availability or Data Consistency? Impact of Network Interruption:  Option A: 1. Some nodes might become inaccessible 2. Reduced system availability 3. Data remains consistent throughout  Option B: 1. Multiple writing nodes ensure system availability 2. The system state might become inconsistent 3. Inconsistencies are addressed later Non-functional requirements  Availability: Describes how long the system is up and running per year.  “Five Nines”, 99.999% of the time online.  Down for a maximum of 5.15 minutes a year.  Data consistency = Linearizability

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

 Scalability: Describes the ability of a system to handle a fast-growing user base and temporary load spikes seamlessly.  Relevant to every system design. There are 2 ways to scale a system:  Vertical Scalability:  Same physical machine -> align with monolithic architecture. Add/replace hardware to the server.  Advantages:  Fast inter-process communication  Data consistency  Disadvantages:  Single point of failure  Economical limit of scalability  Horizontal Scalability:  Adding more physical servers to the cluster  Advantages:  No single bulky server  A cluster of regular services  Scale by adding more servers to the cluster

 Higher availability  Scales linearly  Disadvantage:  Data inconsistency  Complex Architecture  Latency:  Latency is the amount of time in milliseconds (MS) it takes for a single message to be delivered.  The concept applies where data is being requested and transferred.  Caching can be effective to lower latencies. Security: A topic on its own that can be fill a 45-minute interview so avoid this topic, but always mention these things to avoid “red flags”. - Encode network traffic via TLS - API keys to protect API endpoints from DOS(Denial-of-Service) attacks. Quantify Expected Scale:  Daily Active Users (DUA): Key metric to describe their scale. Active users per month (MAU) is common too.  Peak Active Users: Triggered by e.g., global events  Leads to a x time the avg DAU  Example: To-do’s DAU peaks before Christmas.  Good system designs can handle peaks.

 Interactions per User:  Find out about one kind of interaction. (read or write)  User read-write ration to get a holistic view.  Focus only on the core features.  Request Size: Size of the physical of these requests.  Replication Factor: Databases replicate data to multiple nodes. Summary:  Functional Requirements: What the system is supposed to do.  Non-functional: How the system is expected to work. Definitions Load Balancer:  Purpose: More resilient and scalable  Load balancer is a machine that runs reverse proxy software  The goal of the software is to distribute the requests between multiple servers that host the actual application.  Strategies:  Round Robin  Least connections

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

 Resource based  Weighted variants of the above  Random CDN (Content Delivery Network):  Purpose: Servers across the country that can hold our static content.  Static content to store:  Images  CSS  HTML  JavaScript  Types of CDN:  Push  Pull Cache:  Purpose: Stores content to improve read performance and reduce the load.  Caching Strategies:  Cache Aside  Read Through  Write Through

 Write Behind Eviction Policies:  LRU (Least Recently Used)  LFU (Least Frequently Used) Redis:  Redis is the most popular cache solution now  Extremely fast  Limited by RAM  Stores data to disk, but can lose recent data Queues:  Improves scalability and reliability  Buffering  Request spikes smoothing TCP (Transmission Control Protocol -> Most Common)  Back-bone of the internet  Reliable  Sends packages in order, if one package is missing then it will send it again.  Ordered  If a package is missing, then it will start from the missing package.

 Error-checked  If part of the file is missing, then it will send again. Adds checksums to packages.  Slower than other protocols UDP (User Datagram Protocol)  Non-ordered  Used for a constant stream of data  Monitoring metrics  Video streaming  Gaming TCP vs UDP  TCP is slow / UDP is fast  TCP Expects confirmation from the Receiver UDP just sends packets of information  TCP numbers each message  TCP is the most common networking protocol  UDP Good when there’s a constant stream of data HTTP (Hypertext transfer protocol)  Hypertext  Text with links to other documents  Based on TCP

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

 Request-response protocol  Layer 7 Application Request  Method  GET  DELETE  POST  PUT  PATCH (rare)  Partial update  URL  Headers  Body (optional) Response  Status  100-199 Informational (100 Continue – rare)  200-299 Successful (200 OK / 201 Created)  300-399 Redirection (301 Moved permanently)  400-499 Client Error (401 Unauthorized / 403 Forbidden / 404 Not Found)

 500 – 599 Server Error (500 Internal Server Error / 503 Service Unavailable)  Headers  Body (optional) REST  Built on HTTP  Standard URL structure  Standard use for HTTP verbs  HTTP status codes to indicate errors  JSON as body format Web Sockets  Connection is established only once  Real time message delivery to client

System Design Learning

Related Documents