System
Design
An Introduction
Session
Plan
30 Mins - Learn System Design Basics
5 Mins - Quiz and Questions
1 Hour - Learn about evolving system designs
15 Mins - Quick Break
30 Mins - Final System Design
15-20 Mins - Q&A
2 Hrs 45 Mins
System Design
Planning exercise
Cloud Architecture
Software Architecture
Project Structure
Code
Significance
Macro Level View
Systems Thinking, overview
Important for leadership
End to End Product tech understanding
Skillset
Problem Solving
Conceptual understanding of the entire tech
stack and all the technologies
Planning skills, pre-emption
Working with systems that can scale
Real World
Scale
Bottlenecks
Failures
Parking lots have multiple entries
Restaurants have multiple chefs, repeatable
recipes
Gas distribution pipelines have multiple vents,
knobs, checkpoints, parallel pipelines.
Recovery
Technical System Design of OTT Platforms
For Engineers only
Intermediate Level
No Coding
Some prior system
design knowledge will
be helpful
Not relevant for UI/UX
Not relevant for Media, marketing,
Only high level system
designers
social media people
design
Important Pointers
Thousands of people are attending this session.
TRY NOT TO SPAM the chat - it may affect others' learning.
Use the Questions tab for asking questions.
We have limited time - 2 Hrs 45 Mins and there's a lot to cover. Let's use this time to
focus and learn as many concepts as we can.
If you didn't understand something, DO NOT PANIC.
These EXACT sessions repeat often, attend it again in a month or so.
You can watch videos on any of these topics too.
Let's try and keep up - you will have the board and PPTs after the session.
After the session, go through it and things will make sense :)
HLD
Tech components only
Exact technology not discussed
No DSA
No schema design
No API / JSON design
Vs.
LLD
In depth talk about tech
components may not be present
Discusses exact tech.
Will discuss underlying DSA in deep
Will discuss schema design
Will discuss API design
Loadbalancer.
Caching.
Caching.
Caching.
Caching.
Database
Front End
Back End
Scalability.
Latency
Throughput
Capacity
the delay before a transfer of data begins
the amount of data passing through a
the amount of data that the system can
following an instruction for its transfer.
system at a given point of time.
handle / store in entirety.
"Performance is not equal to scalability."
Scalability.
Gunther's universal scalability
Horizontal
Vertical
Add communication constraints and latency
Scaling with distribution.
Distributing data
Distributing compute
Replicating data
Scaling - state.
Stateful
Stateless
Databases - Sharding.
Databases - Replication.
Databases - Indexing.
SQL Vs. NoSQL
Row DBs Vs Column DBs
Services like stock data are Read-heavy systems.
Proxies.
Ratelimiters.
CAP Theorem.
Microservices.
API Gateways.
Ratelimiters and Proxies can
also be rolled into API
Gateways in some cases.
API Composers.
Joins and aggregations are expensive.
API composers do this beforehand
and keep data ready.
Service Registry.
With container and container
orchestration, the IPs of services
change frequently - sometimes on
each deployment.
Web Hooks.
Instead of external services pooling our
APIs for updates, instead we can push
updates to them.
Events.
Synchronous
Asynchronous
Event Queues.
Ordered
Data Stream.
Unordered
Source
Producer
Adapter
The adapter knows how to transform the incompatible data in order to make it
Sink
Consumer
Broker
A message broker is software that enables applications, systems, and
compatible
services to communicate with each other and exchange information
Batch Vs. Streams
Websockets
OTT Platforms - Main Challenges
Traffic spikes
Data is always increasing
To accommodate both data and traffic increase, the system
needs to continuously evolve - divide into smaller chunks.
Netflix started with 5 microservices, now 4000+ microservices
How to evolve from monolith to microservices
OTT Platforms - What you will learn today
Inner workings of OTT platforms
How they evolve their system over a period of time
From interview perspective - just the last part (30 mins).
This is the HOW
Rest of the session is geared towards learning system design
from a Real-world perspective with a simulated case study.
This is the WHY.