S_Leigh_2038: April 2022

Caching | Cache Patterns | Cache Invalidation & Eviction | System Design Tutorials | Part 9 | 2020

This is one of the topics that (like Yogita says at the start of her video) - I really looked forward to findong out more about. This lecture table of contents includes:

What is a cache?
Use Cases
Invalidation & Eviction
Cache Patterns

What is a Cache?

A cache is a way to temporarily store some computed values, such as for example "what is 75 times 75" (5625). The official definition is "a hardware of software component which helps in serving the data that is either frequently requested or expensive to compute, hence the cache saves the response and saves on expensive operations."

Techopedia has the following definition: "Cache memory is a small-sized type of volatile computer memory that provides high-speed data access to a processor and stores frequently used computer programs, applications and data."

Example:

Client requests images from a server. In the first scenario, the request goes from the client to the server to the database and the response goes in the other direction.

If the same response came in from the same or a different client, it would be a waste of computing resources to request it from the database again. Instead, if the image is stored in an in-memory cache, the response time is significantly improved and the load on the database is reduced.

Either the caching can be setup at the server side, such as for example in a reverse proxy.

Or the caching can be done at the client side, such as for example via browser cache or forward proxy.

Frequently requested data is kept in a cache. Another use case for caching is when a client requests information from a server, it sends a request for data from the database, some computation is done and the result is sent in the response. If this same information is requested again - repeating the DB fetch and computation is redundant.

Instead the request and response can be kept in a cache as a key value pair - with the request as a the key and the response as the value.If the request is in the cache, it is referred to as a "cache hit", and if the request is not in the cache, it is called a "cache miss". The cache miss would then result in the database being queried and the cache being updated with the new information.

Invalidation & Eviction

After a period of time, the data in the cache is no longer up to date or relevant. In this instance the cache data needs to be invalidated and replaced or deleted. In an application that shows the daily active users e.g. 5000. After 10 mins the information request can be returned from the cache. However, after 1-2 hours the cache needs to be refreshed - also called "warming up the cache".

Time to Live

Items have a timer: TTL (Time to live) after which the data needs to be replaced. After the TTL expires the item is deleted from the cache. The next data request results in a "cache miss" and new data is retrieved and/or computed, after which the cache is updated again.

If the TTL is too low, the cache is refreshed very frequently and reduces the effectiveness of having a cache in the first place. If the TTL is too high, then the client will be served stale data.

Deciding when to invalidate a cache is a non-deterministic problem and is therefore hard to solve. It depends on each use case to find out what the best cache invalidation strategy and timing to use. The TTL can vary from seconds or minutes to hours or days. Is it more important to have up to date information and hence have more DB hits? Or is it OK to server stale data for a longer time period.

Updating the Cache

Either the old value from the cache is deleted. It will be repopulated after a cache miss and read from DB. An alternative to deleting the data is that as part of the response, the cache value is automatically updated. in some instances, both strategies are used in combination.

Cache Eviction

Due to the limited number of cache keys - if the key limit is exceeded then an existing key needs to be freed up. This is called cache eviction. Below are some examples of cache eviction strategies:

First in, first out
Least recently used

Cache Strategies

Cache Aside Strategy / Pattern

The cache only ever interacts with the application. Never with the server or database. If the database is updated, then either the cache is updated due to entry having it's TTL (time to live) expire - which results in the application getting a cache miss and then updating the cache with the new value. Or there is code in the application that receives notification of a new value in the database (DB) and it then updates the cache.

CodeAhoy: Caching Strategies - Cache Aside

Advantages of this pattern are that if the cache fails - that the application can keep serving the data. The application may slow down due to load on DB, but the system will still remain functioning.

Read Through Strategy / Pattern

In this pattern the cache sits between the application and the database. In this strategy the application always communicates with the cache and never with the database. The first database request will result in a cache miss - that will then trigger the cache to retrieve information from the DB and send it as the response. If there are database changes, the cache is notified and updated without any involvements from the application.

CodeAhoy: Caching Strategies - Read Through

Advantage of this pattern is that is supports read heavy workload such as for example news feeds. Disadvantage is that it always results in a cache miss on the first request. This can be mitigated by "pre-heating the cache", which means populating the cache in advance by sending in a pre-generated list of expected queries.

A key difference between Cache Aside and Read Through is that the latter is often implemented via third party software or library. In addition the modelling of data between the cache and database in Read Through is often similar, whilst for Cache Aside the data modelling can be different.

Write Through Strategy / Pattern

Very similar to read-through pattern and often used in conjunction with the read-through pattern. Application reads and writes to the cache, which is then in turn responsible for updating the database. The disadvantage of this approach is that there is additional time needed for writing to the database - compared to cache aside in which the application writes to the database directly.

Write Around Strategy / Pattern

This pattern tries to use the best of both worlds. The application writes directly to the database, and reads via the cache from the database. So it has the speed of reading from the cache, as well as the speed of writing directly to the database. This strategy is often used when the system has heavy load of write traffic and less read heavy traffic.

Write Back Strategy / Pattern

This is very similar to write through pattern... except that the writes are sent as a batch. So the cache will send an acknowledgement to each write request to the cache, store the write request, and only send it to the database after specific time internal or other condition (such as number of pending writes).

One key advantage of this approach is that it can handle database failure, as the data will be stored for some time in the cache. The main disadvantage of this pattern is that if the cache fails, the database is not updated.

Pros and Cons of each Caching Strategy / Pattern

Cache Aside Pattern

+ Supports heavy reads

+ Works even if cache goes down

- TTL application code have to be used to keep cache and DB consistent

Read/Write Through Pattern

+ Great alternative for read heavy workloads, e.g. news-feed

? Data modelling of cache and DB have to be similar

- Cache failure results in system failure

? Caching layer adds extra layer of latency while writing to the DB (can be solved by 'write around pattern')

Write Back Pattern

+ Useful for write heavy workloads

+ Database failure can be sustained for time cache keeps data in bulk

+ Used by various DB internal applications

- Cache failure results in system failure

Useful links:

Where do I keep the Cache

Caching can be done at client (browser), proxy level, application level, outside of application level, etc. Cache can be used in any of these parts of the system or all of the parts of the system - it really depends on your use cases to which caching locations works best.

Application Programming Interface (API) | System Design Tutorials | Part 8 | 2020

Part 8 Application Programming Interface (API) | System Design Tutorials | Part 8 | 2020

This video topic is about Application Programming Interface (API), in it Yogita goes over:

What is an API?
Examples and Use Cases
Types of APIs
API Standards

APIs are a core part of system design. It is important to understand how they work, what they are used for, and how to design APIs.

What is an API?

Application were discussed in the previous video, see link. The way that one application interacts with another is via code, hence the programmable part. Last but not least, the interface is the defined portal through which one application has entry and exit point for requests or responses.

Applications can run on the same machine, or different machines separated by multiple networks. Each application can be written in a different language. However, through a defined API - the applications can communicate with each other.

Interfaces also add a layer of abstraction, hence one piece of code calling another piece of code does not need (and should not want to) know the internals of the other piece of code. If one application relies on the internal implementation of another application, this tight coupling means that a change in one can (likely will) break the other. By abstracting the interaction via an interface, the applications do not know the internal workings of the other and reduce coupling.

Advantages of an API

Communication - APIs provide a means for two pieces of code to interact with each other.
Abstraction - As mentioned above, APIs provide freedom of implementation. The API provider can refactor or change their implementation and as long as the API behaviour is not changed - there is no impact on the client code calling the API.
Platform Agnostic - The underlying language or platform is not important when two applications communicate over an API.

Examples & Use Cases

Types of APIs include:

Private API - these are hidden APIs that are not accessible to the public. For example, making a payment will involve calling a private API.
Public API - these are accessible to all. For example, Google maps API, weather APIs, etc.
Web API - these are a super-set of private and public APIs.
SDK / Library APIs - a threading library may offer APIs for: lock, fork, join, release lock, etc.

A good example of API documentation is Stripe API: https://stripe.com/docs/api. Stripe provides "payment infrastructure for the internet".

API Factors

In designing complex systems, APIs play a vital role. They are essential for moving data in and our of an application, interacting with other applications, and providing an abstraction layer for this communication.

Good API design involves:

API Contracts
Documentation
Data Formats
Security

The contract defines the type of data communicated, the format, and must be agreed by each side. The documentation contains the contract information and often comes with example code to show how best to interact with the service via the APIs. Data format is a critical factor for designing efficient APIs and security is a of huge importance as it provides and entry point to the application. Each API added increases the attack surface for malicious agents to try to exploit the application to their advantage. Invalid input, rate limiting and throttling, etc are important security considerations in designing an API.

API Standards

Examples of API standards include:

Each has it's own data format, it's Pros and Cons. We'll look in to each of these standards in future blog posts and compare them.

Anatomy of applications and services | System Design Tutorials | Part 7 | 2020

Part 7: Anatomy of applications and services | System Design Tutorials | Part 7 | 2020

Post about Applications and Services.

What is an app / service?
What do applications or services do?
Why do we need them?
Use case / examples
Factors for designing apps
Surprising sub-topic

Using the example of a building, the water, electricity, elevators, etc. are all application equivalents. In client-server architecture.... the client side code sends requests to the server side code expecting a response.

Examples of client side applications are: DropBox, EverNote, Netflix, Browser, etc. For EverNote, the desktop/mobile/web app communicates to back-end server application. This in turn handles storing the notes, handling user profile, payments, authentication & authorisation, etc. Multiple back-end applications can interact with each other to fulfil a client side request.

Technology Stack:

The back-end stack could include:

Python
Java
Go
PHP

Front-end stack could include:

Java / Kotlin
Swift / Objective-C
Web / JavaScript

In addition to the languages listed for back-end (and front-end) there are frameworks that support development. For example Spring Boot, Laravel, DJango. The frameworks speed up development time, reduce common coding bugs (as it's a single code-base), and have been thoroughly tested by multiple users.

Front-end and Back-end interactions via APIs are language agnostic.

Responsibilities:

Front-end application responsibilities include:

Render UI elements
Handle interactions
Collect Data
Communicate with Back-End APIs to fetch/store data
Render static data/information

Back-end application responsibilities include:

Expose API endpoint
House business logic
Handle data modelling / transformation
Interact with data stores
Interact with other services

Elements / Factors of Application Design / Development:

Requirement
Layers
Technology Stack
Code structure / Design patterns
Data store interactions
Performance / cost
Deployment
Monitoring
Operational Excellence / Reliability

If, for example, this list was used for designing a parking lot app - it would have the following considerations:

Requirement - e.g. number of parking slots, sizes, and floor. Finding car based on number plate, find next available slot, etc.
Layers - this indicates if app will be desktop, mobile, server side CLI (command line interface)
Technology Stack - for example a web app might have HTML/CSS, JavaScript, and React for front-end and Java with Spring Boot for back-end.
Code structure / Design patterns - this contains the business logic, as well as logic for user handling and database storage & retrieval
Data store interactions - often abstracted to be generic, whether data is read and written to disc or cache is determined by the use cases for the system.
Performance / cost - especially for front-end applications the memory and CPU usage may slow down the application. On the server side, too much processing or storage can also have a cost impact if utilised in a pay per use cloud solution.
Deployment - whether hosted on cloud, on premises, etc is determined by the expected scaling needed to support the user base.
Monitoring - is very important to reduce cost, investigate and fix crashes, as well as understand customer usage of the application.
Operational Excellence / Reliability - application should be able to handle incorrect or unexpected inputs, it should fail gracefully when for example there is limited or no internet connectivity.

Surprise topic:

If a single application handles creating/storing notes, payments, user profiles - this is referred to as a monolith. Usually small companies start with a monolithic architecture.

As the user base scales and services need to be split off - this is called micro-service based architecture that interact with each other to satisfy user requests.

Databases types: SQL, NoSQL, Column, Search, Key Value | System Design Tutorials | Part 6 | 2020

Part 6 of Yogita Sharma System Design Tutorial: Databases types: SQL, NoSQL, Column, Search, Key Value.

This video covers:

Types of Databases
Pros and Cons
Use Cases
Examples

Depending on the properties of the data and the volume of data that may need to be queried - different types of databases are commended for use. Different types of databases include:

Relational
Non-relational
File
Network

Non-relational databases can be further subdivided into:

Key-Value Stores
Column based DBs
Document based DBs
Search DBs

RELATIONAL DATABASES

Regarding relational databases, two main properties determine which types of relational databases are best to use:

Schema
ACID

1. Schema

The schema describes how data will be structures. An example of constraints used in database creation include:

Primary Key
Not Null
Foreign Key
Int
VARCHAR
Default

create table EMPLOYEES {
id INT PRIMARY KEY,
name VARCHAR(50) NOT NULL,
age INT,
department_id INT NOT NULL,
FOREIGN KEY (department_id) REFERENCES department (Id)
}

The database help design complex relations between data. Databases also prevent garbage data such as null value is not populated. As well as ensuring that all other schema constraints are being adhered to.

2. ACID

The acronym stands for:

Atomocity

Either a transaction is handled in its entirety or not at all
An example of this is moving money between accounts

Consistency

Data is... well consistent.
For example, if two separate read operations are run on the same data - they must not return different results.

Isolation

Processing of one transaction cannot depend on another, they should not know about each other.
For example, a read of data, followed by a write to adjust the data read - does not result in another read.

Durability

Data needs to persist

Transactional systems such as banking are suited to using relational databases. If on the other hand the schema is not fixed, then a non-relational database is much more appropriate. Relational databases are very easy to scale vertically. This means providing more computing resources, such as memory to store the data. Horizontal scaling, splitting the work between multiple machines, is more challenging with relational databases.

NON-RELATIONAL DATABASES (also known as NoSQL)

Non-relational databases do not have a fixed schema.

Key-Value pair databases consist of keys and values that are accessed via hash of the key. Caches use key : value pairs. Examples include: Redis, Dynamo DB, Memcached. Since key look-up is fast - access in key-value DBs is speedy and some DBs are stored in memory ensuring faster access than DBs using file read from storage.

Document based databases are used when the schema is not fixed and heavy reads and writes are part of common use case. Document DBs have collections and documents. The collection is like a table and the document is like a row. Having all the data in one place makes it easier to query as multiple tables do not need to be read. However, since there is no schema - parts of a document may have null values. Another con to using document based DBs is that they do not guarantee ACID properties. This can be compensated for using application code.

In summary, regarding NoSQL databses - here are the pros and cons.

Pros:

Highly scaleable
Sharding
Dynamic Data Flexibility
Special query operations / aggregation

Cons:

Cannot guarantee that data does not include null values
Cannot guarantee ACID properties

Column Based DBs are a half-way solution between key : value pairs and document based DBs. They have fixed tables and schema, however they do not guarantee ACID properties. They are best used when there are heavy reads such as streaming data. Other examples include health tracking information or dta captured from IoT (Internet of Things) devices. The table structure is based on the types of reads expected. A music streaming service might have a column based DB with tables for users, songs, users_by_liked_songs, and songs_by_users_liked.

Examples of Column based DBs include: Cassandra, HBase, Scylla.

Search databases contain information about queries and advances indexes. Examples of search based DBs include: Elastic Search, Solar. A search database is often not the primary data store, it references the primary data story and refreshes it's data based on popular queries.

Other types of data are stored in specialist databases. Image and Videos are often stored in S3, and Bucket. Large data sets contain data from large number of users, data from IoT devices, or data captured over time.

Sometimes it's obvious which database type is the best to use in a system. Other times it's not and the type of database may need to change as common use cases from customers become clear or the type of data entering the system would be better stored in a different type of database. Some large companies even create their own database solutons.

Data & Data Flow | System Design Tutorials | Part 5 | 2020

Part 5 of Yogita Sharma System Design Tutorial: Data & Data Flow

Items for review in this video are:

Data
Data Format / Representation
Mechanisms for Data Flow
Factors: Type, Volume, Scale, Purpose

The example is given that in buildings such as hospitals, schools, theatre, bank, or hotels - people interact in those places. Here the people represent the data and the buildings are the systems with which the data is associated.

Data is at the Core of System Design

Business Layer -> Text, videos, images
Application Layer -> JSON/XML
Data Stores (DBs) -> Tables, indexes, lists, trees
Network layer -> Packets
Hardware Layer -> Zeros and Ones

Network Layers (source)

As data moved between the layers, it is transformed to allow transmission, receiving, or storage of data. When designing systems, the three layers that always need to be considered are: business, application, and data layer. Data needs to flow in efficient manner and data needs to be stored in secure and effective manner.

Understanding what the data is that the system is handling, how it will flow through the system, and how it is stored is half the work of system design.

Data stores, and example data, include:

Database

Username, phone number, city, address

Queues

Send SMS Request, Send Email Request

Cache

Request : Response, images

Indexes

Most searched items, Searches from past 1 hour

Data flows include:

APIs
Messages
Events

Data can be generated from a number of different sources, including for example:

Users
Internal
Insights
Sensor input

Internal data includes data about other data. For example, if a user creates a profile for a game. Then how many hours a person spends on each game would form part of the data about data - information about the user who is represented in their gaming profile.

Factors relating to Data:

When designing the system - not only do data flow and data storage play a critical role - so too does the type of data.

Types of Data
Volume
Consumption / Retrieval
Sensitivity

An example of differences in how data is handled is comparing text processing with video processing. The former may be parsed, analysed, transformed, and transmitted without breaking up the units of texts. Video may be sliced in to segments, transformed and processed in parallel, and then put back in the correct order - as the size of the data compared to text is much larger.

Systems consuming gigabytes versus those consuming terabytes vary significantly. Some systems may consume more than they produce and vice versa. Volume and whether to read and/or write - are major factors for deciding how to design the system.

Below are some example systems and their data flows:

Authorisation system

User login, identity management
Volume is low
Security and priority levels are high

Streaming service

Netflix, BBC iPlayer, Prime Video
Volume is high
Data retrieval is also high

Transactional Systems

E-commerce, Ride-share app, grocery ordering app
Validation is high priority
Paths of the data flow are very important to ensure consistency

Heavy compute systems

Image recognition systems, video processing using machine learning models
These systems have little retrieval, however they do have a lot of upload and computation

Next we'll look at how best to store data and their use cases.

Proxies | System Design Tutorials | Part 4 | 2020

Part 4 of Yogita Sharma System Design Tutorial: Proxies

This video is about Proxies:

Defining what proxies are
Forward proxy
Reverse proxy
Pros & Cons and use cases

The term proxy means "on behalf of". Meriam-Webster dictionary defines it as "authority or power to act for another". A real life example includes asking a broker to act on your behalf when seeking to rent or buy an apartment.

Forward and Reverse Proxy by cysecguide.blogspot.com

Forward Proxy

In client-server architecture, the proxy is on the client side which forwards requests to the servers and receives the responses - that are passed back to the client. The client never talks directly to the server and the benefit is that the client is anonymous - the server does not know the IP of the client.

In addition, in a situation where there are multiple proxies communicating with a single proxy - it can cache responses and improve the user experience with the client. Forward proxies can also act to filter outward traffic and block specific traffic requests.

Reverse Proxy

The reverse proxy acts as a middle man between the internet and all the servers. This ensures the anonymity of the servers. It is used for traffic control, load balancing betwen servers, and deflate the impacts of Distributed Denial of Service (cloudflare link) (DDoS) attacks. Reverse proxies can also cache responses and handle SSL/TLS (cloudflare link) encryption.

Pros and Cons of Proxies

Proxy can be used to block sites
Proxies can be used to circumvent blocked sites
Reverse proxy can be single point of failure
Proxies help with privacy, security, and traffic management

Client Server Architecture | System Design Tutorials | Part 3 | 2020

Part 3 of Yogita Sharma System Design Tutorial.

Taking a look at our first component: Client-Server Architecture
Specifically: Client, Server, Thick Client, Thin Client, 2-Tier / 3-Ties / N-Tier

What is Client-Server Architecture?

Image courtesy of GeeksForGeeks

Client initiates request from server to receive, for example, an image or a text file
Servers sends back response with the requested information
For some requests, data manipulation needs to be done on data. Logic is applied at the server to the request. For example, send filtered list houses within geographic and monetary range.
The above diagram is represents basic 2 tier architecture.

Thick and Thin Clients

Thick client means that (some of) the application programming logic is on the client side
Thin client means that (most of) the application programming logic is on the server side
Examples of thick clients where processing is done at client side include Outlook and video processing software.
Examples of thin clients are streaming services such as Netflix and Youtube
To summarise the 3 elements of client server architecture include: presentation, logic, and data
Where the data is processed and logic applied, determines if it is a thick or thin client

2-Tier, 3-Ties, and N-Tier Architectures

In setups where there is a lot of application logic or if the data is vast - then the server is broken up according to logic and data.
Hence there are now 3 tiers: client, logic, and data.
Once load-balancers are introduced between client and logic, cache is introduced between logic and data - the setup is now n-ties architecture.
For simple streaming services or e-commerce sites - a thin client is best approach.
For video editing apps, desktop games, or other processing intensive applications - thick client is best approach.
For simple website for small business - 2-tier architecture is fine
For application with more complex business logic - 3-tier architecture works better.
When serving a large number of users - n-tier architecture is likely more suitable

Components of System Design | System Design Tutorials | Part 2 | 2020

Part 2 of Yogita Sharma System Design Tutorial.

Components are the basic building blocks of system and consist of two types:

Logical Entities
Tangible Entities

Logical Entities:

At the core of logical entities is data, which is stored in databases.
Users can interact with databases via applications,
Typical operations are create, read, update, delete (CRUD)
Applications and databases use communication protocols, which are also logical entities
Communication protocols such as HTTP, TCP/IP over networks
The presentation (front-end) application communicates to the server (on a separate machine) via protocols such as HTTP, RPC, APIs
Some systems, such as logging systems, do not have presentation layer
All of these logical entities run on computers, often on a machine run by a cloud provider
Examples of logical entities include:

Data
Database
Application
Cache
Message Queues
Infra
Communication

Tangible Entities:

Examples of logical tangible include

Text, images, videos
MongoDB, MySQL, Cassandra
Java, Golang, Python, React
Redis, MemCache
Kafka, RabbitMQ
AWS, Google Cloud Platform, Azure
APIs, RPCs, Messages

Cloud providers instantiate tangible entities listed above in order to provide a working environment for businesses to provide services to other businesses or users
A simple system setup is shown below:

Courtesy of vasanthk Gist

The Request could come from the user via front-end app on mobile, laptop, etc via browser or dedicated application.
Physical computers provisioned by cloud providers run the load balancers, web servers, and databases that data and respond to the user.
The physical and tangible entities in the diagram above as often referred to as "infrastructure".

System Design Book Recommendations from Yogita Sharma

Yogita Sharma in the following video shares her top 5 book recommendations. I too learn more from books than YouTube videos. Here are the recommended books and the Amazon links.

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems by Martin Kleppmann

Great introductory text that is useful for any software developer.

System Design Interview – An insider's guide by Alex Xu

Author provides a clear framework how to answer system design questions. Author also has volume 2 in print.

Solutions Architect's Handbook: Kick-start your career as a solutions architect by learning architecture design principles and strategies, 2nd Edition 2nd ed. Edition by Saurabh Shrivastava (Author), Neelanjali Srivastav (Author), Rajesh Sheth (Foreword), Rohan Karmarkar (Foreword), Kamal Arora (Foreword)

For people looking to move to architect role, contains chapters specifically on System Design

Fundamentals of Software Architecture: An Engineering Approach by Mark Richards (Author), Neal Ford (Author)

Similar to above, specific parts of the book focus on system design. Section on different architectural styles is useful such as: layer, service-based, event-based architecture. Also covers fundamental topics such as topology, latency, networks failures.

Operating Systems: Three Easy Pieces by Remzi H Arpaci-Dusseau (Author), Andrea C Arpaci-Dusseau (Author)

Very useful for developing design mind-set. Covers topics such as shared memory, files-systems, concurrency, etc. Consider what happens when these components are scaled to distributed system.

Learning System Design

Youtube, books, tutorials, and blogs are all great sources of learning about System Design. In this series of blog posts, I will primarily be learning from Yogita Sharma and Gaurav Sen.

In Introduction to System Design | System Design Tutorials | Part 1 | 2020 - Yogita Sharma describes System Design as: "Architecture or series of technologies -> that serve a set of users -> to fulfil a set of requirements".

What is a System?

Real world systems include hotels, hospitals, train stations, etc.
Computing systems include WhatsApp, Snapchat, Netxlifx, etc.
Components of real world systems include: walls, ceiling & floor, electrical systems, water supply, lighting, heating systems, etc.
Components of computing systems include: databases, servers, caches, applications, message queues, etc.

What is Design?

Understanding the needs of the users
Selecting the right components
Working within constraints
The combination of the above is what makes up design
Design of two story building and skyscraper will be different, even though similar components may be used.
Being able to scale systems is why System Design as a discipline has evolved

System Design

Designing large scale systems is done by a team
It requires understanding of the components, their strengths and weaknesses
What the trade offs are and when to best use each component
How to build a system that scales well within specific constraints

Yogita's YouTube course is about looking at each component, their strengths and weaknesses. Then to combine them and build large scale computing systems.

Followers