System Design Concepts Course and Interview Prep

00:53:38
https://www.youtube.com/watch?v=F2FmTdLtb_4

Ringkasan

TLDRThe tutorial comprehensively covers system design, focusing on scalability, reliability, data handling, and high-level architecture. It is structured to help viewers prepare for system design interviews by explaining core concepts and practical strategies. Key topics include understanding computer architecture, load balancing, caching, networking protocols, and API design. The CAP theorem is discussed to highlight trade-offs in system design. Various database types and scaling strategies are explored, along with load balancing techniques using proxy servers. The importance of redundancy, cache evictions, and network traffic management is emphasized to build efficient and resilient systems.

Takeaways

  • 💡 Scalability is crucial in system design for handling increased loads and ensuring growth.
  • ⚙️ High-level architecture serves as the blueprint for designing robust systems.
  • 📦 Caching data optimizes performance by reducing data retrieval times.
  • 🔍 Understanding the CAP theorem helps make informed trade-offs.
  • 🔗 Load balancers distribute network traffic to prevent overloading on a single server.
  • 🗂️ Different database types serve unique needs, from SQL to NoSQL to in-memory databases.
  • 📌 Proxies act as intermediaries, with types like forward and reverse proxies enhancing security and performance.
  • 🔐 Networking fundamentals, including IP addresses and protocols, are key to system communication.
  • 🚦 API design, including REST, GraphQL, and gRPC, can drastically affect system efficiency.
  • 🔄 Consistent health checks ensure server and system components are always operational.

Garis waktu

  • 00:00:00 - 00:05:00

    This video is a comprehensive guide on system design, emphasizing the importance of understanding the high-level architecture of computers before delving into larger distributed systems. It covers the basics of computer storage including bits, bytes, and more complex units like terabytes. It explains the differences between SSD and HDD storage, highlighting the speed advantages of SSDs. The video also discusses RAM, its use for active processes, and the concept of cache alongside CPU operations.

  • 00:05:00 - 00:10:00

    The next section focuses on the architecture of a production-ready application, starting with the CI/CD pipeline for automated code deployment using platforms like Jenkins. It describes how user requests are managed through load balancers and external storage systems, along with communication between multiple servers. Logging and monitoring systems are crucial for detecting system anomalies, and developers are advised to debug issues in non-production environments.

  • 00:10:00 - 00:15:00

    A discussion on system design principles follows, stressing scalability, maintainability, and efficiency. It highlights the importance of planning for system failures and discusses the CAP theorem's trade-offs between consistency, availability, and partition tolerance. The concept of system availability is linked to SLAs and SLOs, illustrating the goal of high uptime for essential services.

  • 00:15:00 - 00:20:00

    Networking basics are covered, starting with IP addresses and the use of IPv4 and IPv6. It explains how data is transmitted over a network using packets, and the roles of TCP and UDP at the transport layer. The importance of DNS for translating domain names into IP addresses is also mentioned, along with the foundational role of application layer protocols in web communication.

  • 00:20:00 - 00:25:00

    The section on application layer protocols delves deeper into HTTP and its status codes, while explaining the functionality of WebSockets for real-time communication. The video details the use of SMTP, IMAP, and POP3 for email, FTP and SSH for file transfers, and WebRTC and MQTT for real-time communication. RPC is also discussed as a method for executing remote procedures, emphasizing its wide application.

  • 00:25:00 - 00:30:00

    Next, the video explores API design best practices, using an e-commerce platform as an example. It discusses implementing CRUD operations, designing endpoints, and choosing between REST, GraphQL, and gRPC paradigms. The importance of maintaining backward compatibility and setting rate limits is stressed to ensure efficient API performance and user satisfaction.

  • 00:30:00 - 00:35:00

    Caching and content delivery networks (CDNs) are introduced as strategies to reduce latency and improve user experience. The video describes browser, server, database, and CDN caching, detailing how each type helps store data temporarily for quicker access. Different strategies, such as push and pull CDN methods, are covered to highlight their benefits.

  • 00:35:00 - 00:40:00

    Proxy servers, both forward and reverse, serve different functions in managing client-server interactions. Forward proxies assist with privacy and content filtering, while reverse proxies handle load balancing, caching, and SSL termination. The advantages of employing proxies in network management are outlined, including improved security and performance.

  • 00:40:00 - 00:45:00

    Load balancing strategies are detailed, explaining algorithms such as round robin, least connections, and IP hashing. The video describes the importance of continuous server health checks to ensure traffic is directed appropriately. Popular load balancer types, from hardware to software solutions, and their role in preventing system overload are examined.

  • 00:45:00 - 00:53:38

    Finally, the video addresses databases in system design, explaining different types such as SQL and NoSQL, their scaling methods, and performance improvement techniques such as sharding and indexing. The ACD principles are highlighted, alongside the trade-offs of the CAP theorem. It summarizes strategies to ensure database efficiency and reliability in distributed systems.

Tampilkan lebih banyak

Peta Pikiran

Mind Map

Pertanyaan yang Sering Diajukan

  • What are the main topics covered in this system design tutorial?

    The tutorial covers scalability, reliability, data handling, and high-level architecture with real-world examples.

  • What is the importance of understanding high-level architecture in system design?

    Understanding high-level architecture is crucial before designing large-scale, distributed systems.

  • How are computers structured to execute code?

    Computers function through a layered system, starting from binary data (bits and bytes), progressing through storage types (RAM, SSD, HDD), and utilizing cache and CPUs.

  • What role do load balancers and reverse proxies play in system design?

    Load balancers and reverse proxies distribute user requests evenly across multiple servers to maintain smooth performance even during traffic spikes.

  • What are the key principles of good design in system architecture?

    Scalability, maintainability, efficiency, planning for failure, and building resilient systems are the key principles.

  • What is the CAP theorem in system design?

    The CAP theorem outlines the trade-offs between consistency, availability, and partition tolerance in distributed systems, asserting that you can only prioritize two.

  • How does caching improve system performance?

    Caching stores copies of data for faster access, reducing latency and server load by serving frequently requested data from a closer location.

  • What are the common types of databases discussed in the tutorial?

    Relational databases (SQL), NoSQL databases, and in-memory databases are discussed, each serving different use cases.

  • What strategies are used for effective load balancing?

    Common load balancing strategies include round-robin, least connections, least response time, IP hashing, and weighted algorithms.

  • What are proxy servers and their types?

    Proxy servers act as intermediaries between clients and servers, existing in types like forward proxies, reverse proxies, and open proxies.

Lihat lebih banyak ringkasan video

Dapatkan akses instan ke ringkasan video YouTube gratis yang didukung oleh AI!
Teks
en
Gulir Otomatis:
  • 00:00:00
    this complete system design tutorial
  • 00:00:02
    covers scalability reliability data
  • 00:00:04
    handling and high level architecture
  • 00:00:07
    with clear explanations real world
  • 00:00:09
    examples and practical strategies hike
  • 00:00:12
    will teach you the Core Concepts you
  • 00:00:14
    need to know for a system designs
  • 00:00:17
    interview this is a complete crash
  • 00:00:19
    course on system design interview
  • 00:00:21
    Concepts that you need to know to as
  • 00:00:23
    your job interview the system design
  • 00:00:25
    interview doesn't have to do much with
  • 00:00:27
    coding and people don't want to see you
  • 00:00:28
    write actual code but how you glue an
  • 00:00:30
    entire system together and that is
  • 00:00:32
    exactly what we're going to cover in
  • 00:00:34
    this tutorial we'll go through all of
  • 00:00:36
    the concepts that you need to know to as
  • 00:00:38
    your job interview before designing
  • 00:00:41
    large scale distributed systems it's
  • 00:00:43
    important to understand the high level
  • 00:00:45
    architecture of the individual computer
  • 00:00:47
    let's see how different parts of the
  • 00:00:49
    computer work together to execute our
  • 00:00:52
    code computers function through a
  • 00:00:54
    layered system each optimized for
  • 00:00:56
    varying tasks at Decor computers
  • 00:00:59
    understand only binary zeros and ones
  • 00:01:02
    these are represented as bits one bit is
  • 00:01:05
    the smallest data unit in Computing it
  • 00:01:07
    can be either zero or one one bite
  • 00:01:11
    consists of eight bits and it's used to
  • 00:01:13
    represent a single character like a or
  • 00:01:15
    number like one expanding from here we
  • 00:01:18
    have kilobyte megabyte gigabytes and
  • 00:01:21
    terabytes to store this data we have
  • 00:01:24
    computer disk storage which holds the
  • 00:01:26
    primary data it can be either htd or SS
  • 00:01:30
    D type the disk storage is nonvolatile
  • 00:01:33
    it maintains data without power meaning
  • 00:01:35
    if you turn off or restart the computer
  • 00:01:38
    the data will still be there it contains
  • 00:01:41
    the OS applications and all user files
  • 00:01:44
    in terms of size discs typically range
  • 00:01:46
    from hundreds of gigabytes to multiple
  • 00:01:49
    terabytes while ssds are more expensive
  • 00:01:53
    they offer significantly faster data
  • 00:01:55
    retrieval than HDD for instance an SSD
  • 00:01:58
    may have a r speed of 500 MB per second
  • 00:02:01
    to
  • 00:02:02
    3,500 while an HDD might offer 80 to 160
  • 00:02:07
    mb per second the next immediate access
  • 00:02:10
    point after dis is the Ram or random
  • 00:02:12
    access memory RAM serves as the primary
  • 00:02:15
    active data holder and it holds data
  • 00:02:18
    structures variables and applications
  • 00:02:20
    data that are currently in use or being
  • 00:02:23
    processed when a program runs its
  • 00:02:26
    variables intermediate computations
  • 00:02:28
    runtime stack and more are stored in Ram
  • 00:02:31
    because it allows for a quick read and
  • 00:02:33
    write access this is a volatile memory
  • 00:02:36
    which means that it requires power to
  • 00:02:38
    retain its contents and after you
  • 00:02:40
    restart the computer the data may not be
  • 00:02:43
    persisted in terms of size Rams range
  • 00:02:46
    from a few Gaby in consumer devices to
  • 00:02:49
    hundreds of gabt in high-end
  • 00:02:52
    servers their read right speed often
  • 00:02:54
    surpasses 5,000 megabytes per second
  • 00:02:57
    which is faster than even the fastest SS
  • 00:03:00
    this dis speed but sometimes even this
  • 00:03:02
    speed isn't enough which brings us to
  • 00:03:04
    the cache the cache is smaller than Ram
  • 00:03:07
    typically it's measured in megabytes but
  • 00:03:10
    access times for cach memory are even
  • 00:03:12
    faster than Ram offering just a few Nan
  • 00:03:15
    for the L1 cache the CPU first checks
  • 00:03:18
    the L1 cach for the data if it's not
  • 00:03:21
    found it checks the L2 and L3 cache and
  • 00:03:24
    then finally it checks the ram the
  • 00:03:26
    purpose of a cach is to reduce the
  • 00:03:28
    average time to Access Data that's why
  • 00:03:31
    we store frequently used data here to
  • 00:03:33
    optimize CPU performance and what about
  • 00:03:36
    the CPU CPU is the brain of the computer
  • 00:03:40
    it fetches decodes and executes
  • 00:03:42
    instructions when you run your code it's
  • 00:03:44
    the CPU that processes the operations
  • 00:03:47
    defined in that program but before it
  • 00:03:49
    can run our code which is written in
  • 00:03:51
    high level languages like Java C++
  • 00:03:54
    python or other languages our code first
  • 00:03:57
    needs to be compiled into machine code a
  • 00:04:00
    compiler performs this translation and
  • 00:04:02
    once the code is compiled into machine
  • 00:04:04
    code the CPU can execute it it can read
  • 00:04:07
    and write from our Ram disk and cach
  • 00:04:09
    data and finally we have motherboard or
  • 00:04:12
    main board which is what you might think
  • 00:04:14
    of as the component that connects
  • 00:04:16
    everything it provides the path phase
  • 00:04:19
    that allow data to flow between these
  • 00:04:21
    components now let's have a look at the
  • 00:04:23
    very high level architecture of a
  • 00:04:25
    production ready up our first key area
  • 00:04:28
    is the cicd pipeline continuous
  • 00:04:30
    integration and continuous deployment
  • 00:04:32
    this ensures that our code goes from the
  • 00:04:34
    repository through a series of tests and
  • 00:04:37
    pipeline checks and onto the production
  • 00:04:39
    server without any manual intervention
  • 00:04:42
    it's configured with platforms like
  • 00:04:44
    Jenkins or GitHub actions for automating
  • 00:04:46
    our deployment
  • 00:04:47
    processes and once our app is in
  • 00:04:50
    production it has to handle lots of user
  • 00:04:52
    requests this is managed by our load
  • 00:04:54
    balancers and reverse proxies like
  • 00:04:57
    ngx they ensure that the user request
  • 00:04:59
    are evenly distributed across multiple
  • 00:05:01
    servers maintaining a smooth user
  • 00:05:04
    experience even during traffic specs our
  • 00:05:07
    server is also going to need to store
  • 00:05:09
    data for that we also have an external
  • 00:05:11
    storage server that is not running on
  • 00:05:13
    the same production server instead it's
  • 00:05:16
    connected over a
  • 00:05:17
    network our servers might also be
  • 00:05:20
    communicating with other servers as well
  • 00:05:22
    and we can have many such services not
  • 00:05:24
    just one to ensure everything runs
  • 00:05:27
    smoothly we have logging and monitoring
  • 00:05:29
    system s keeping a Keen Eye on every
  • 00:05:31
    micro interaction of storing logs and
  • 00:05:33
    analyzing data it's standard practice to
  • 00:05:36
    store logs on external Services often
  • 00:05:38
    outside of our primary production server
  • 00:05:42
    for the back end tools like pm2 can be
  • 00:05:44
    used for logging and monitoring on the
  • 00:05:46
    front end platforms like Sentry can be
  • 00:05:48
    used to capture and Report errors in
  • 00:05:51
    real time and when things don't go as
  • 00:05:53
    plann meaning our logging systems detect
  • 00:05:55
    failing requests or anomalies first it
  • 00:05:58
    enforce our alerting service after that
  • 00:06:01
    push notifications are sent to keep
  • 00:06:03
    users informed from generic something
  • 00:06:05
    rank wrong to specific payment failed
  • 00:06:07
    and modern practice is to integrate
  • 00:06:09
    these alerts directly into platforms we
  • 00:06:12
    commonly use like slack imagine a
  • 00:06:14
    dedicated slack Channel where alerts pop
  • 00:06:16
    up at the moment an issue arises this
  • 00:06:19
    allows developers to jump into action
  • 00:06:21
    almost instantly addressing the root CS
  • 00:06:23
    before it escalates and after that
  • 00:06:26
    developers have to debug the issue first
  • 00:06:28
    and foremost the issue needs to be
  • 00:06:30
    identified those logs we spoke about
  • 00:06:32
    earlier they are our first Port of Call
  • 00:06:35
    developers go through them searching for
  • 00:06:37
    patterns or anomalies that could point
  • 00:06:39
    to the source of the problem after that
  • 00:06:41
    it needs to be replicated in a safe
  • 00:06:43
    environment the golden rule is to never
  • 00:06:46
    debug directly in the production
  • 00:06:47
    environment instead developers recreate
  • 00:06:50
    the issue in a staging or test
  • 00:06:52
    environment this ensures users don't get
  • 00:06:54
    affected by the debugging process then
  • 00:06:57
    developers use tools to peer into the
  • 00:06:58
    running app apption and start debugging
  • 00:07:01
    once the bug is fixed a hot fix is
  • 00:07:03
    rolled out this is a quick temporary fix
  • 00:07:06
    designed to get things running again
  • 00:07:08
    it's like a patch before a more
  • 00:07:09
    permanent solution can be implemented in
  • 00:07:12
    this section let's understand the
  • 00:07:13
    pillars of system design and what it
  • 00:07:16
    really takes to create a robust and
  • 00:07:17
    resilent application now before we jump
  • 00:07:20
    into the technicalities let's talk about
  • 00:07:23
    what actually makes a good design when
  • 00:07:25
    we talk about good design in system
  • 00:07:27
    architecture we are really focusing ing
  • 00:07:29
    on a few key principles scalability
  • 00:07:32
    which is our system growth with its user
  • 00:07:34
    base maintainability which is ensuring
  • 00:07:37
    future developers can understand and
  • 00:07:39
    improve our system and efficiency which
  • 00:07:42
    is making the best use of our resources
  • 00:07:45
    but good design also means planning for
  • 00:07:47
    failure and building a system that not
  • 00:07:49
    only performs well when everything is
  • 00:07:51
    running smoothly but also maintains its
  • 00:07:54
    composure when things go wrong at the
  • 00:07:57
    heart of system design are three key
  • 00:07:58
    elements moving data storing data and
  • 00:08:01
    transforming data moving data is about
  • 00:08:05
    ensuring that data can flow seamlessly
  • 00:08:07
    from one part of our system to another
  • 00:08:10
    whether it's user request seeding our
  • 00:08:12
    servers or data transfers between
  • 00:08:14
    databases we need to optimize for Speed
  • 00:08:17
    and security storing data isn't just
  • 00:08:19
    about choosing between SQL or nosql
  • 00:08:22
    databases it's about understanding
  • 00:08:24
    access patterns indexing strategies and
  • 00:08:27
    backup Solutions we need to ensure that
  • 00:08:29
    our data is not only stored securely but
  • 00:08:31
    is also readily available when needed
  • 00:08:34
    and data transformation is about taking
  • 00:08:37
    row data and turning it into meaningful
  • 00:08:39
    information whether it's aggregating log
  • 00:08:42
    files for analysis or converting user
  • 00:08:44
    input into a different format now let's
  • 00:08:47
    take a moment to understand the crucial
  • 00:08:49
    Concept in system design the cap theorem
  • 00:08:52
    also known as Brewers theorem named
  • 00:08:54
    after computer scientist Eric Brewer
  • 00:08:57
    this theorem is a set of principles that
  • 00:08:59
    guide us in making informed tradeoffs
  • 00:09:01
    between three key components of a
  • 00:09:03
    distributed system consistency
  • 00:09:06
    availability and partition tolerance
  • 00:09:09
    consistency ensures that all nodes in
  • 00:09:11
    the distributed system have the same
  • 00:09:13
    data at the same time if you make a
  • 00:09:15
    change to one node that change should
  • 00:09:17
    also be reflected across all nodes think
  • 00:09:20
    of it like updating a Google doc if one
  • 00:09:23
    person makes an edit everyone else sees
  • 00:09:25
    that edit immediately availability means
  • 00:09:28
    that the system is is always operational
  • 00:09:30
    and responsive to requests regardless of
  • 00:09:33
    what might be happening behind the
  • 00:09:34
    scenes like a reliable online store no
  • 00:09:37
    matter when you visit it's always open
  • 00:09:40
    and ready to take your order and
  • 00:09:42
    partition tolerance refers to the
  • 00:09:44
    system's ability to continue functioning
  • 00:09:47
    even when a network partition occur
  • 00:09:49
    meaning if there is a disruption in
  • 00:09:51
    communication between nodes the system
  • 00:09:53
    still works it's like having a group
  • 00:09:55
    chat where even if one person loses
  • 00:09:57
    connection the rest of the group can
  • 00:09:59
    continue chatting and according to cap
  • 00:10:02
    theorem a distributed system can only
  • 00:10:04
    achieve two out of these three
  • 00:10:05
    properties at the same time if you
  • 00:10:08
    prioritize consistency and partition
  • 00:10:10
    tolerance you might have to compromise
  • 00:10:12
    on availability and vice versa for
  • 00:10:15
    example a banking system needs to be
  • 00:10:17
    consistent and partition tolerant to
  • 00:10:19
    ensure Financial accuracy even if it
  • 00:10:22
    means some transactions take longer to
  • 00:10:24
    process temporarily compromising
  • 00:10:27
    availability so every design DEC
  • 00:10:29
    decision comes with tradeoffs for
  • 00:10:31
    example a system optimized for read
  • 00:10:33
    operations might perform poorly on write
  • 00:10:35
    operations or in order to gain
  • 00:10:38
    performance we might have to sacrifice a
  • 00:10:40
    bit of complexity so it's not about
  • 00:10:42
    finding the perfect solution it's about
  • 00:10:44
    finding the best solution for our
  • 00:10:46
    specific use case and that means making
  • 00:10:48
    informed decision about where we can
  • 00:10:51
    afford to compromise so one important
  • 00:10:53
    measurement of system is availability
  • 00:10:56
    this is the measure of systems
  • 00:10:58
    operational performance and
  • 00:11:00
    reliability when we talk about
  • 00:11:02
    availability we are essentially asking
  • 00:11:04
    is our system up and running when our
  • 00:11:06
    users need it this is often measured in
  • 00:11:09
    terms of percentage aiming for that
  • 00:11:11
    golden 5 9's availability let's say we
  • 00:11:14
    are running a critical service with 99.9
  • 00:11:17
    availability that allows for around 8.76
  • 00:11:21
    hours of downtime per year but if we add
  • 00:11:24
    two NES to it we are talking just about
  • 00:11:27
    5 minutes of downtime per year and
  • 00:11:29
    that's a massive difference especially
  • 00:11:31
    for services where every second counts
  • 00:11:34
    we often measure it in terms of uptime
  • 00:11:36
    and downtime and here is where service
  • 00:11:38
    level objectives and service level
  • 00:11:40
    agreements come into place slos are like
  • 00:11:43
    setting goals for our systems
  • 00:11:45
    performance and availability for example
  • 00:11:48
    we might set an SLO stating that our web
  • 00:11:50
    service should respond to request within
  • 00:11:52
    300 milliseconds and
  • 00:11:54
    99.9% of the time slas on the other hand
  • 00:11:58
    are like for formal contracts with our
  • 00:12:00
    users or customers they Define the
  • 00:12:02
    minimum level of service we are
  • 00:12:04
    committing to provide so if our SLA
  • 00:12:07
    guarantees 99.99 availability and we
  • 00:12:10
    drop below that we might have to provide
  • 00:12:12
    refunds or other compensations to our
  • 00:12:15
    customers building resilence into our
  • 00:12:18
    system means expecting the unexpected
  • 00:12:20
    this could mean implementing redundant
  • 00:12:22
    systems ensuring there is always a
  • 00:12:24
    backup ready to take over in case of
  • 00:12:26
    failure or it could mean designing our
  • 00:12:29
    system to degrade gracefully so even if
  • 00:12:32
    certain features are unavailable the
  • 00:12:34
    core functionality remains intact to
  • 00:12:36
    measure this aspect we used reliability
  • 00:12:39
    fault tolerance and
  • 00:12:41
    redundancy reliability means ensuring
  • 00:12:44
    that our system works correctly and
  • 00:12:46
    consistently fa tolerance is about
  • 00:12:48
    preparing for when things go wrong how
  • 00:12:51
    does our system handle unexpected
  • 00:12:53
    failures or attacks and redundancy is
  • 00:12:56
    about having backups ensuring that if
  • 00:12:58
    one part of our system fails there is
  • 00:13:00
    another ready to take its place we also
  • 00:13:03
    need to measure the speed of our system
  • 00:13:05
    and for that we have throughput and
  • 00:13:07
    latency throughput measures how much
  • 00:13:10
    data our system can handle over a
  • 00:13:12
    certain period of time we have server
  • 00:13:14
    throughput which is measured in requests
  • 00:13:16
    per second this metric provides an
  • 00:13:19
    indication of how many client requests a
  • 00:13:21
    server can handle in a given time frame
  • 00:13:24
    a higher RPS value typically indicates
  • 00:13:27
    better performance and the ability to
  • 00:13:29
    handle more concurrent users we have
  • 00:13:31
    database throughput which is measured in
  • 00:13:34
    queries per second this quantifies the
  • 00:13:36
    number of queries a database can process
  • 00:13:39
    in a second like server throughput a
  • 00:13:41
    higher QPS value usually signifies
  • 00:13:44
    better
  • 00:13:45
    performance and we also have data
  • 00:13:47
    throughput which is measured in bytes
  • 00:13:49
    per second this reflects the amount of
  • 00:13:51
    data transferred over a network or
  • 00:13:54
    processed by a system in a given period
  • 00:13:56
    of time on the other hand latency
  • 00:13:59
    measures how long it takes to handle a
  • 00:14:00
    single request it's the time it takes
  • 00:14:03
    for a request to get a response and
  • 00:14:05
    optimizing for one can often lead to
  • 00:14:08
    sacrifices in the other for example
  • 00:14:10
    batching operations can increase
  • 00:14:12
    throughput but might also increase
  • 00:14:14
    latency and designing a system poly can
  • 00:14:17
    lead to a lot of issues down the line
  • 00:14:19
    from performance bottlenecks to security
  • 00:14:22
    vulnerabilities and unlike code which
  • 00:14:24
    can be refactored easily redesigning A
  • 00:14:26
    system can be a Monumental task that's
  • 00:14:29
    why it's crucial to invest time and
  • 00:14:31
    resources into getting the design right
  • 00:14:33
    from the start and laying a solid
  • 00:14:35
    foundation that can support the weight
  • 00:14:37
    of future features and user growth now
  • 00:14:40
    let's talk about networking Basics when
  • 00:14:42
    we talk about networking Basics we are
  • 00:14:44
    essentially discussing how computers
  • 00:14:46
    communicate with each other at the heart
  • 00:14:49
    of this communication is the IP address
  • 00:14:51
    a unique identifier for each device on a
  • 00:14:54
    network IP V4 addresses are 32bit which
  • 00:14:57
    allows for approximately 4 billion
  • 00:14:59
    unique addresses however with the
  • 00:15:02
    increasing number of devices we are
  • 00:15:04
    moving to IP V6 which uses 128bit
  • 00:15:07
    addresses significantly increasing the
  • 00:15:09
    number of available unique addresses
  • 00:15:12
    when two computers communicate over a
  • 00:15:14
    network they send and receive packets of
  • 00:15:16
    data and each packet contains an IP
  • 00:15:19
    header which contains essential
  • 00:15:21
    information like the senders and
  • 00:15:23
    receivers IP addresses ensuring that the
  • 00:15:25
    data reaches the correct destination
  • 00:15:28
    this process is governed by the Internet
  • 00:15:30
    Protocol which is a set of rules that
  • 00:15:32
    defines how data is sent and received
  • 00:15:35
    besides the IP layer we also have the
  • 00:15:38
    application layer where data specific to
  • 00:15:40
    the application protocol is stored the
  • 00:15:43
    data in these packets is formatted
  • 00:15:45
    according to specific application
  • 00:15:47
    protocol data like HTTP for web browsing
  • 00:15:50
    so that the data is interpreted
  • 00:15:52
    correctly by the receiving device once
  • 00:15:55
    we understand the basics of Ip
  • 00:15:57
    addressing and data packets we can dive
  • 00:15:59
    into transport layer where TCP and UDP
  • 00:16:02
    come into play TCP operates at the
  • 00:16:05
    transport layer and ensures reliable
  • 00:16:08
    communication it's like a delivery guy
  • 00:16:10
    who makes sure that your package not
  • 00:16:12
    only arrives but also checks that
  • 00:16:14
    nothing is missing so each data packet
  • 00:16:16
    also includes a TCP header which is
  • 00:16:19
    carrying essential information like port
  • 00:16:21
    numbers and control flux necessary for
  • 00:16:24
    managing the connection and data flow
  • 00:16:26
    TCP is known for its reliability it
  • 00:16:29
    ensures the complete and correct
  • 00:16:31
    delivery of data packets it accomplishes
  • 00:16:34
    this through features like sequence
  • 00:16:35
    numbers which keep track of the order of
  • 00:16:38
    packets and the process known as the
  • 00:16:40
    freeway handshake which establishes a
  • 00:16:42
    stable connection between two devices in
  • 00:16:45
    contrast UDP is faster but less reliable
  • 00:16:48
    than TCP it doesn't establish a
  • 00:16:51
    connection before sending data and
  • 00:16:53
    doesn't guarantee the delivery or order
  • 00:16:55
    of the packets but this makes UDP
  • 00:16:58
    preferable for time sensitive
  • 00:17:00
    Communications like video calls or live
  • 00:17:02
    streaming where speed is crucial and
  • 00:17:05
    some data loss is acceptable to tie all
  • 00:17:08
    these Concepts together let's talk about
  • 00:17:10
    DNS domain name system DNS acts like the
  • 00:17:13
    internet form book translating human
  • 00:17:16
    friendly domain names into IP addresses
  • 00:17:19
    when you enter a URL in your browser the
  • 00:17:21
    browser sends a DNS query to find the
  • 00:17:24
    corresponding IP address allowing it to
  • 00:17:26
    establish a connection to the server and
  • 00:17:28
    and retrieve the web page the
  • 00:17:30
    functioning of DNS is overseen by I can
  • 00:17:33
    which coordinates the global IP address
  • 00:17:35
    space and domain name system and domain
  • 00:17:39
    name registers like name chip or gold Ed
  • 00:17:41
    are accredited by I can to sell domain
  • 00:17:44
    names to the public DNS uses different
  • 00:17:47
    types of Records like a records which
  • 00:17:49
    map The Domain to its corresponding IP
  • 00:17:52
    address ensuring that your request
  • 00:17:54
    reaches to the correct server or 4 a
  • 00:17:57
    records which map a domain name name to
  • 00:17:59
    an IP V6 address and finally let's talk
  • 00:18:03
    about the networking infrastructure
  • 00:18:05
    which supports all these communication
  • 00:18:07
    devices on a network have either public
  • 00:18:10
    or private IP addresses public IP
  • 00:18:13
    addresses are unique across the internet
  • 00:18:15
    while private IP addresses are unique
  • 00:18:17
    within a local network an IP address can
  • 00:18:20
    be stated permanently assigned to a
  • 00:18:23
    device or dynamic changing over time
  • 00:18:25
    Dynamic IP addresses are commonly used
  • 00:18:28
    for res idential internet connections
  • 00:18:30
    and devices connected in a local area
  • 00:18:33
    network can communicate with each other
  • 00:18:36
    directly and to protect these networks
  • 00:18:38
    we are using firewalls which are
  • 00:18:40
    monitoring and controlling incoming and
  • 00:18:42
    outgoing Network traffic and within a
  • 00:18:46
    device specific processes or services
  • 00:18:48
    are identified by ports which when
  • 00:18:50
    combined with an IP address create a
  • 00:18:52
    unique identifier for a network service
  • 00:18:56
    some ports are reserved for specific
  • 00:18:58
    protocols like 80 for HTTP or 22 for
  • 00:19:02
    SSH now let's cover all the essential
  • 00:19:05
    application layer protocols the most
  • 00:19:07
    common protocol out of this is HTTP
  • 00:19:09
    which stands for hyper text transfer
  • 00:19:11
    protocol which is built on TCP IP it's a
  • 00:19:14
    request response protocol but imagine it
  • 00:19:17
    as a conversation with no memory each
  • 00:19:19
    interaction is separate with no
  • 00:19:21
    recollection of the past this means that
  • 00:19:24
    the server doesn't have to store any
  • 00:19:25
    context between requests instead each
  • 00:19:28
    request contains all the necessary
  • 00:19:30
    information and notice how the headers
  • 00:19:33
    include details like URL and Method
  • 00:19:35
    while body carries the substance of the
  • 00:19:37
    request or response each response also
  • 00:19:40
    includes the status code which is just
  • 00:19:42
    to provide feedback about the result of
  • 00:19:44
    a client's request on a server for
  • 00:19:47
    instance 200 series are success codes
  • 00:19:50
    these indicate that the request was
  • 00:19:51
    successfully received and processed 300
  • 00:19:55
    series are redirection codes this
  • 00:19:57
    signify that further action needs to be
  • 00:20:00
    taken by the user agent in order to
  • 00:20:02
    fulfill the request 400 series are
  • 00:20:06
    client error codes these are used when
  • 00:20:08
    the request contains bad syntax or
  • 00:20:10
    cannot be fulfilled and 500 series are
  • 00:20:13
    server error codes this indicates that
  • 00:20:15
    something went wrong on the server we
  • 00:20:18
    also have a method on each request the
  • 00:20:21
    most common methods are get post put
  • 00:20:23
    patch and delete get is used for
  • 00:20:25
    fetching data post is usually for
  • 00:20:27
    creating a data on server puted patch
  • 00:20:30
    are for updating a record and delete is
  • 00:20:33
    for removing a record from database HTTP
  • 00:20:36
    is oneway connection but for realtime
  • 00:20:39
    updates we use web sockets that provide
  • 00:20:41
    a two-way Communication channel over a
  • 00:20:43
    single long lift connection allowing
  • 00:20:46
    servers to push real-time updates to
  • 00:20:48
    clients this is very important for
  • 00:20:50
    applications requiring constant data
  • 00:20:52
    updates without the overhead of repeated
  • 00:20:55
    HTTP request response Cycles it is
  • 00:20:58
    commonly used for chat applications live
  • 00:21:00
    sport updates or stock market feeds
  • 00:21:03
    where the action never stops and neither
  • 00:21:05
    does the
  • 00:21:06
    conversation from email related
  • 00:21:08
    protocols SMTP is the standard for email
  • 00:21:11
    transmission over the Internet it is the
  • 00:21:14
    protocol for sending email messages
  • 00:21:16
    between servers most email clients use
  • 00:21:19
    SMTP for sending emails and either IMAP
  • 00:21:22
    or pop free for retrieving them imup is
  • 00:21:25
    used to retrieve emails from a server
  • 00:21:27
    allowing a client to access and
  • 00:21:29
    manipulate messages this is ideal for
  • 00:21:31
    users who need to access their emails
  • 00:21:33
    from multiple
  • 00:21:35
    devices pop free is used for downloading
  • 00:21:37
    emails from a server to a local client
  • 00:21:40
    typically used when emails are managed
  • 00:21:42
    from a single device moving on to file
  • 00:21:45
    transfer and management protocols the
  • 00:21:47
    traditional protocol for transferring
  • 00:21:49
    files over the Internet is FTP which is
  • 00:21:53
    often used in Website Maintenance and
  • 00:21:55
    large data transfers it is used for the
  • 00:21:58
    trans of files between a client and
  • 00:22:00
    server useful for uploading files to
  • 00:22:02
    server or backing up files and we also
  • 00:22:05
    have SSH or secure shell which is for
  • 00:22:08
    operating Network Services securely on
  • 00:22:10
    an unsecured Network it's commonly used
  • 00:22:13
    for logging into a remote machine and
  • 00:22:15
    executing commands or transferring files
  • 00:22:19
    there are also real-time communication
  • 00:22:21
    protocols like web RTC which enables
  • 00:22:24
    browser to browser applications for
  • 00:22:26
    voice calling video chat and file Shar
  • 00:22:28
    sharing without internal or external
  • 00:22:30
    plugins this is essential for
  • 00:22:32
    applications like video conferencing and
  • 00:22:35
    live
  • 00:22:36
    streaming another one is mqtt which is a
  • 00:22:39
    lightweight messaging protocol ideal for
  • 00:22:41
    devices with limited processing power
  • 00:22:43
    and in scenarios requiring low bandwidth
  • 00:22:46
    such as iot devices and amqp is a
  • 00:22:50
    protocol for message oriented middleware
  • 00:22:52
    providing robustness and security for
  • 00:22:55
    Enterprise level message communication
  • 00:22:57
    for example it is used in tools like
  • 00:22:59
    rabbit mq let's also talk about RPC
  • 00:23:03
    which is a protocol that allows a
  • 00:23:04
    program on one computer to execute code
  • 00:23:07
    on a server or another computer it's a
  • 00:23:10
    method used to invoke a function as if
  • 00:23:12
    it were a local call when in reality the
  • 00:23:15
    function is executed on a remote machine
  • 00:23:18
    so it abstracts the details of the
  • 00:23:20
    network communication allowing the
  • 00:23:22
    developer to interact with remote
  • 00:23:24
    functions seamlessly as if they were
  • 00:23:26
    local to the application and many
  • 00:23:28
    application player protocols use RPC
  • 00:23:31
    mechanisms to perform their operations
  • 00:23:33
    for example in web services HTTP
  • 00:23:36
    requests can result in RPC calls being
  • 00:23:38
    made on backend to process data or
  • 00:23:41
    perform actions on behalf of the client
  • 00:23:43
    or SMTP servers might use RPC calls
  • 00:23:46
    internally to process email messages or
  • 00:23:49
    interact with
  • 00:23:51
    databases of course there are numerous
  • 00:23:53
    other application layer protocols but
  • 00:23:55
    devance covered here are among the most
  • 00:23:57
    commonly used Bo and essential for web
  • 00:24:00
    development in this section let's go
  • 00:24:02
    through the API design starting from the
  • 00:24:04
    basics and advancing towards the best
  • 00:24:06
    practices that Define exceptional apis
  • 00:24:09
    let's consider an API for an e-commerce
  • 00:24:11
    platform like Shopify which if you're
  • 00:24:13
    not familiar with is a well-known
  • 00:24:15
    e-commerce platform that allows
  • 00:24:17
    businesses to set up online stores in
  • 00:24:19
    API design we are concerned with
  • 00:24:21
    defining the inputs like product details
  • 00:24:24
    for a new product which is provided by a
  • 00:24:26
    seller and the output like the
  • 00:24:29
    information returned when someone
  • 00:24:30
    queries a product of an API so the focus
  • 00:24:33
    is mainly on defining how the crow
  • 00:24:35
    operations are exposed to the user
  • 00:24:38
    interface CR stands for create read
  • 00:24:40
    update and delete which are basic
  • 00:24:43
    operations of any data driven
  • 00:24:45
    application for example to add a new
  • 00:24:47
    product we need to send a post request
  • 00:24:49
    to/ API products where the product
  • 00:24:53
    details are sent in the request body to
  • 00:24:55
    retrieve these products we need to send
  • 00:24:57
    the get request requ EST to/ API SL
  • 00:25:00
    products for updating we use put or
  • 00:25:02
    patch requests to/ product/ the ID of
  • 00:25:06
    that product and removing is similar to
  • 00:25:09
    updating it's again/ product/ ID of the
  • 00:25:12
    product we need to remove and similarly
  • 00:25:15
    we might also have another get request
  • 00:25:17
    to/ product/ ID which fetches the single
  • 00:25:20
    product another part is to decide on the
  • 00:25:23
    communication protocol that will be used
  • 00:25:25
    like HTTP websockets or other protocols
  • 00:25:29
    and the data transport mechanism which
  • 00:25:31
    can be Json XML or protocol buffers this
  • 00:25:35
    is usually the case for restful apis but
  • 00:25:38
    we also have graphql and grpc paradigms
  • 00:25:41
    so apis come in different paradigms each
  • 00:25:44
    with its own set of protocols and
  • 00:25:46
    standards the most common one is rest
  • 00:25:49
    which stands for representational State
  • 00:25:51
    transfer it is stateless which means
  • 00:25:53
    that each request from a client to a
  • 00:25:55
    server must contain all the information
  • 00:25:57
    needed to understand and complete the
  • 00:26:00
    request it uses standard HTTP methods
  • 00:26:03
    get post put and delete and it's easily
  • 00:26:07
    consumable by different clients browsers
  • 00:26:09
    or mobile apps the downside of restful
  • 00:26:12
    apis is that they can lead to over
  • 00:26:14
    fetching or under fetching of data
  • 00:26:17
    because more endpoints may be required
  • 00:26:18
    to access specific data and usually
  • 00:26:21
    restful apis use Json for data exchange
  • 00:26:25
    on the other hand graphql apis allow
  • 00:26:27
    clients to request exactly what they
  • 00:26:29
    need avoiding over fetching and under
  • 00:26:31
    fetching data they have strongly typed
  • 00:26:35
    queries but complex queries can impact
  • 00:26:37
    server performance and all the requests
  • 00:26:40
    are sent as post requests and graphql
  • 00:26:43
    API typically responds with HTTP 200
  • 00:26:46
    status code even in case of errors with
  • 00:26:49
    error details in the response body grpc
  • 00:26:52
    stands for Google remote procedure call
  • 00:26:55
    which is built on http2 which provides
  • 00:26:57
    advanced featur features like
  • 00:26:58
    multiplexing and server push it uses
  • 00:27:02
    protocol buffers which is a way of
  • 00:27:03
    serializing structured data and because
  • 00:27:07
    of that it's sufficient in terms of
  • 00:27:08
    bandwidth and resources especially
  • 00:27:10
    suitable for
  • 00:27:12
    microservices the downside is that it's
  • 00:27:14
    less human readable compared to Json and
  • 00:27:17
    it requires http2 support to operate in
  • 00:27:21
    an e-commerce setting you might have
  • 00:27:23
    relationships like user to orders or
  • 00:27:25
    orders to products and you need to
  • 00:27:28
    design endpoints to reflect these
  • 00:27:29
    relationships for example to fetch the
  • 00:27:32
    orders for a specific user you need to
  • 00:27:34
    query to get/ users SL the user id/
  • 00:27:38
    orders common queries also include limit
  • 00:27:41
    and offset for pagination or start and
  • 00:27:44
    end date for filtering products within a
  • 00:27:46
    certain date range this allows users or
  • 00:27:49
    the client to retrieve specific sets of
  • 00:27:51
    data without overwhelming the system a
  • 00:27:55
    well-designed get request should be itm
  • 00:27:57
    ponent meaning calling it multiple times
  • 00:27:59
    doesn't change the result and it should
  • 00:28:01
    always return the same result and get
  • 00:28:04
    requests should never mutate data they
  • 00:28:06
    are meant only for retrieval if you need
  • 00:28:09
    to update or create a data you need to
  • 00:28:11
    do a put or post request when modifying
  • 00:28:14
    end points it's important to maintain
  • 00:28:16
    backward compatibility this means that
  • 00:28:19
    we need to ensure that changes don't
  • 00:28:21
    break existing clients a common practice
  • 00:28:24
    is to introduce new versions like
  • 00:28:26
    version two products so that the version
  • 00:28:29
    one API can still serve the old clients
  • 00:28:32
    and version 2 API should serve the
  • 00:28:33
    current clients this is in case of
  • 00:28:36
    restful apis in the case of graph Co
  • 00:28:39
    apis adding new Fields like V2 Fields
  • 00:28:42
    without removing old one helps in
  • 00:28:44
    evolving the API without breaking
  • 00:28:46
    existing clients another best practice
  • 00:28:49
    is to set rate limitations this can
  • 00:28:52
    prevent the API from Theos attacks it is
  • 00:28:55
    used to control the number of requests a
  • 00:28:57
    user can make in certain time frame and
  • 00:29:00
    it prevents a single user from sending
  • 00:29:02
    too many requests to your single API a
  • 00:29:05
    common practice is to also set course
  • 00:29:08
    settings which stands for cross origin
  • 00:29:10
    resource sharing with course settings
  • 00:29:13
    you can control which domains can access
  • 00:29:15
    to your API preventing unwanted
  • 00:29:17
    cross-site interactions now imagine a
  • 00:29:20
    company is hosting a website on a server
  • 00:29:22
    in Google cloud data centers in Finland
  • 00:29:25
    it may take around 100 milliseconds to
  • 00:29:27
    load for users in Europe but it takes 3
  • 00:29:30
    to 5 Seconds to load for users in Mexico
  • 00:29:33
    fortunately there are strategies to
  • 00:29:35
    minimize this request latency for users
  • 00:29:37
    who are far away these strategies are
  • 00:29:39
    called caching and content delivery
  • 00:29:41
    networks which are two important
  • 00:29:43
    Concepts in modern web development and
  • 00:29:45
    system design caching is a technique
  • 00:29:48
    used to improve the performance and
  • 00:29:50
    efficiency of a system it involves
  • 00:29:52
    storing a copy of certain data in a
  • 00:29:54
    temporary storage so that future
  • 00:29:56
    requests for that data can be served
  • 00:29:58
    faster there are four common places
  • 00:30:01
    where cash can be stored the first one
  • 00:30:03
    is browser caching where we store
  • 00:30:05
    website resources on a user's local
  • 00:30:07
    computer so when a user revisits a site
  • 00:30:10
    the browser can load the site from the
  • 00:30:12
    local cache rather than fetching
  • 00:30:14
    everything from the server again users
  • 00:30:16
    can disable caching by adjusting the
  • 00:30:19
    browser settings in most browsers
  • 00:30:21
    developers can disable cach from the
  • 00:30:23
    developer tools for instance in Chrome
  • 00:30:25
    we have the disable cache option in the
  • 00:30:27
    dev Vel opers tools Network tab the cach
  • 00:30:30
    is stored in a directory on the client's
  • 00:30:32
    hard drive managed by the browser and
  • 00:30:35
    browser caches store HTML CSS and JS
  • 00:30:38
    bundle files on the user's local machine
  • 00:30:40
    typically in a dedicated cache directory
  • 00:30:43
    managed by the browser we use the cache
  • 00:30:46
    control header to tell browser how long
  • 00:30:48
    this content should be cached for
  • 00:30:50
    example here the cache control is set to
  • 00:30:53
    7,200 seconds which is equivalent to 2
  • 00:30:56
    hours when the re ested data is found in
  • 00:30:59
    the cache we call that a cash hit and on
  • 00:31:01
    the other hand we have cash Miss which
  • 00:31:03
    happens when the requested data is not
  • 00:31:05
    in the cash necessitating a fetch from
  • 00:31:07
    the original source and cash ratio is
  • 00:31:10
    the percentage of requests that are
  • 00:31:12
    served from the cach compared to all
  • 00:31:14
    requests and the higher ratio indicates
  • 00:31:16
    a more effective cach you can check if
  • 00:31:18
    the cash fall hit or missed from the
  • 00:31:20
    xcash header for example in this case it
  • 00:31:23
    says Miss so the cash was missed and in
  • 00:31:26
    case the cash is found we will have here
  • 00:31:27
    it here we also have server caching
  • 00:31:30
    which involves storing frequently
  • 00:31:32
    accessed data on the server site
  • 00:31:34
    reducing the need to perform expensive
  • 00:31:36
    operations like database queries serers
  • 00:31:39
    side caches are stored on a server or on
  • 00:31:41
    a separate cache server either in memory
  • 00:31:44
    like redis or on disk typically the
  • 00:31:47
    server checks the cache from the data
  • 00:31:49
    before quering the database if the data
  • 00:31:51
    is in the cach it is returned directly
  • 00:31:53
    otherwise the server queries the
  • 00:31:56
    database and if the data is not in the
  • 00:31:58
    cache the server retrieves it from the
  • 00:32:00
    database returns it to the user and then
  • 00:32:03
    stores it in the cache for future
  • 00:32:05
    requests this is the case of right
  • 00:32:07
    around cache where data is written
  • 00:32:09
    directly to permanent storage byp
  • 00:32:11
    passing the cache it is used when right
  • 00:32:14
    performance is less critical you also
  • 00:32:16
    have write through cache where data is
  • 00:32:18
    simultaneously written to cache and the
  • 00:32:21
    permanent storage it ensures data
  • 00:32:23
    consistency but can be slower than right
  • 00:32:25
    round cache and we also have right back
  • 00:32:28
    cach where data is first written to the
  • 00:32:30
    cache and then to permanent storage at a
  • 00:32:32
    later time this improves right
  • 00:32:34
    performance but you have a risk of
  • 00:32:36
    losing that data in case of a crush of
  • 00:32:39
    server but what happens if the cash is
  • 00:32:41
    full and we need to free up some space
  • 00:32:43
    to use our cash again for that we have
  • 00:32:46
    eviction policies which are rules that
  • 00:32:48
    determine which items to remove from the
  • 00:32:50
    cash when it's full common policies are
  • 00:32:53
    to remove least recently used ones or
  • 00:32:56
    first in first out where we remove the
  • 00:32:58
    ones that were added first or removing
  • 00:33:00
    the least frequently used ones database
  • 00:33:03
    caching is another crucial aspect and it
  • 00:33:05
    refers to the practice of caching
  • 00:33:07
    database query results to improve the
  • 00:33:09
    performance of database driven
  • 00:33:11
    applications it is often done either
  • 00:33:14
    within the database system itself or via
  • 00:33:16
    an external caching layer like redies or
  • 00:33:19
    M cache when a query is made we first
  • 00:33:21
    check the cache to see if the result of
  • 00:33:24
    that query has been stored if it is we
  • 00:33:26
    return the cach state avoiding the need
  • 00:33:28
    to execute the query against the
  • 00:33:30
    database but if the data is not found in
  • 00:33:33
    the cache the query is executed against
  • 00:33:35
    the database and the result is stored in
  • 00:33:37
    the cache for future requests this is
  • 00:33:40
    beneficial for read heavy applications
  • 00:33:42
    where some queries are executed
  • 00:33:45
    frequently and we use the same eviction
  • 00:33:47
    policies as we have for server side
  • 00:33:49
    caching another type of caching is CDN
  • 00:33:52
    which are a network of servers
  • 00:33:54
    distributed geographically they are
  • 00:33:56
    generally used to serf static content
  • 00:33:58
    such as JavaScript HTML CSS or image and
  • 00:34:01
    video files they cat the content from
  • 00:34:04
    the original server and deliver it to
  • 00:34:06
    users from the nearest CDN server when a
  • 00:34:09
    user requests a file like an image or a
  • 00:34:11
    website the request is redirected to the
  • 00:34:14
    nearest CDN server if the CDN server has
  • 00:34:17
    the cached content it delivers it to the
  • 00:34:19
    user if not it fetches the content from
  • 00:34:22
    the origin server caches it and then
  • 00:34:24
    forwards it to the user this is the pool
  • 00:34:27
    based type type of CDN where the CDN
  • 00:34:29
    automatically pulls the content from the
  • 00:34:31
    origin server when it's first requested
  • 00:34:33
    by a user it's ideal for websites with a
  • 00:34:36
    lot of static content that is updated
  • 00:34:38
    regularly it requires less active
  • 00:34:41
    management because the CDN automatically
  • 00:34:43
    keeps the content up to date another
  • 00:34:46
    type is push based CDs this is where you
  • 00:34:48
    upload the content to the origin server
  • 00:34:51
    and then it distributes these files to
  • 00:34:52
    the CDN this is useful when you have
  • 00:34:55
    large files that are infrequently
  • 00:34:57
    updated but need to be quickly
  • 00:34:58
    distributed when updated it requires
  • 00:35:01
    more active management of what content
  • 00:35:03
    is stored on the edn we again use the
  • 00:35:06
    cache control header to tell the browser
  • 00:35:08
    for how long it should cach the content
  • 00:35:10
    from CDN CDN are usually used for
  • 00:35:13
    delivering static assets like images CSS
  • 00:35:16
    files JavaScript bundles or video
  • 00:35:18
    content and it can be useful if you need
  • 00:35:21
    to ensure High availability and
  • 00:35:22
    performance for users it can also reduce
  • 00:35:25
    the load on the origin server but there
  • 00:35:28
    are some instances where we still need
  • 00:35:29
    to hit our origin server for example
  • 00:35:32
    when serving Dynamic content that
  • 00:35:34
    changes frequently or handling tasks
  • 00:35:37
    that require real-time processing and in
  • 00:35:39
    cases where the application requires
  • 00:35:41
    complex server side logic that cannot be
  • 00:35:44
    done in the CDN some of the benefits
  • 00:35:46
    that we get from CDN are reduced latency
  • 00:35:50
    by serving content from locations closer
  • 00:35:52
    to the user CDN significantly reduce
  • 00:35:55
    latency it also adds High avail ability
  • 00:35:58
    and scalability CDN can handle high
  • 00:36:01
    traffic loads and are resilent against
  • 00:36:03
    Hardware failures it also adds improved
  • 00:36:06
    security because many CDN offer security
  • 00:36:09
    features like DDS protection and traffic
  • 00:36:11
    encryption and the benefits of caching
  • 00:36:14
    are also reduced latency because we have
  • 00:36:16
    fast data retrieval since the data is
  • 00:36:18
    fetched from the nearby cache rather
  • 00:36:20
    than a remote server it lowers the
  • 00:36:23
    server load by reducing the number of
  • 00:36:25
    requests to the primary data source
  • 00:36:27
    decreasing server load and overall
  • 00:36:30
    faster load times lead to a better user
  • 00:36:32
    experience now let's talk about proxy
  • 00:36:35
    servers which act as an intermediary
  • 00:36:37
    between a client requesting a resource
  • 00:36:39
    and the server providing that resource
  • 00:36:42
    it can serve various purposes like
  • 00:36:44
    caching resources for faster access
  • 00:36:46
    anonymizing requests and load balancing
  • 00:36:49
    among multiple servers essentially it
  • 00:36:51
    receives requests from clients forwards
  • 00:36:53
    them to the relevant servers and then
  • 00:36:56
    Returns the servers respond back to the
  • 00:36:58
    client there are several types of proxy
  • 00:37:00
    servers each serving different purposes
  • 00:37:03
    here are some of the main types the
  • 00:37:05
    first one is forward proxy which sits in
  • 00:37:08
    front of clients and is used to send
  • 00:37:10
    requests to other servers on the
  • 00:37:12
    Internet it's often used within the
  • 00:37:15
    internal networks to control internet
  • 00:37:17
    access next one is reverse proxy which
  • 00:37:20
    sits in front of one or more web servers
  • 00:37:22
    intercepting requests from the internet
  • 00:37:25
    it is used for load balancing web
  • 00:37:27
    acceleration and as a security layer
  • 00:37:30
    another type is open proxy which allows
  • 00:37:33
    any user to connect and utilize the
  • 00:37:35
    proxy server often used to anonymize web
  • 00:37:38
    browsing and bypass content restrictions
  • 00:37:41
    we also have transparent proxy types
  • 00:37:43
    which passes along requests and
  • 00:37:45
    resources without modifying them but
  • 00:37:47
    it's visible to the client and it's
  • 00:37:49
    often used for caching and content
  • 00:37:51
    filtering next type is anonymous proxy
  • 00:37:54
    which is identifiable as a proxy server
  • 00:37:57
    but but does not make the original IP
  • 00:37:59
    address available this type is used for
  • 00:38:02
    anonymous browsing we also have
  • 00:38:04
    distorting proxies which provides an
  • 00:38:06
    incorrect original Ip to the destination
  • 00:38:09
    server this is similar to an anonymous
  • 00:38:11
    proxy but with purposeful IP
  • 00:38:14
    misinformation and next popular type is
  • 00:38:16
    high anonymity proxy or Elite proxy
  • 00:38:19
    which makes detecting the proxy use very
  • 00:38:22
    difficult these proxies do not send X
  • 00:38:24
    forwarded for or other identifying
  • 00:38:27
    header and they ensure maximum anonymity
  • 00:38:30
    the most commonly used proxy servers are
  • 00:38:32
    forward and reverse proxies a forward
  • 00:38:35
    proxy acts as a middle layer between the
  • 00:38:37
    client and the server it sits between
  • 00:38:40
    the client which can be a computer on an
  • 00:38:42
    internal Network and the external
  • 00:38:44
    servers which can be websites on the
  • 00:38:47
    internet when the client makes a request
  • 00:38:49
    it is first sent to the forward proxy
  • 00:38:52
    the proxy then evaluates the request and
  • 00:38:54
    decides based on its configuration and
  • 00:38:57
    rules whether to allow the request
  • 00:38:59
    modify it or to block it one of the
  • 00:39:02
    primary functions of a forward proxy is
  • 00:39:04
    to hide the client's IP address when it
  • 00:39:07
    forwards the request to the Target
  • 00:39:09
    server it appears as if the request is
  • 00:39:12
    coming from the proxy server itself
  • 00:39:14
    let's look at some example use cases of
  • 00:39:17
    forward proxies one popular example is
  • 00:39:20
    Instagram proxies these are a specific
  • 00:39:23
    type of forward proxy used to manage
  • 00:39:25
    multiple Instagram accounts without
  • 00:39:27
    triggering bonds or restrictions and
  • 00:39:30
    marketers and social media managers use
  • 00:39:32
    Instagram proxies to appear as if they
  • 00:39:34
    are located in different area or as
  • 00:39:37
    different users which allows them to
  • 00:39:39
    manage multiple accounts automate tasks
  • 00:39:42
    or gather data without being flaged for
  • 00:39:44
    suspicious activity next example is
  • 00:39:47
    internet use control and monitoring
  • 00:39:49
    proxies some organizations use forward
  • 00:39:52
    proxies to Monitor and control employee
  • 00:39:55
    internet usage they can block access to
  • 00:39:57
    non-related sites and protect against
  • 00:40:00
    web based threats they can also scan for
  • 00:40:03
    viruses and malware in incoming content
  • 00:40:06
    next common use case is caching
  • 00:40:08
    frequently accessed content forward
  • 00:40:10
    proxies can also cach popular websites
  • 00:40:13
    or content reducing bandwidth usage and
  • 00:40:15
    speeding up access for users within the
  • 00:40:18
    network this is especially beneficial in
  • 00:40:21
    networks where bandwidth is costly or
  • 00:40:23
    limited and it can be also used for
  • 00:40:26
    anonymizing web access people who are
  • 00:40:28
    concerned about privacy can use forward
  • 00:40:30
    proxies to hide their IP address and
  • 00:40:33
    other identifying information from
  • 00:40:35
    websites they Vis it and making it
  • 00:40:38
    difficult to track their web browsing
  • 00:40:40
    activities on the other hand the reverse
  • 00:40:42
    proxy is a type of proxy server that
  • 00:40:45
    sits in front of one or more web servers
  • 00:40:47
    intercepting requests from clients
  • 00:40:49
    before they reach the servers while a
  • 00:40:52
    forward proxy hides the client's
  • 00:40:54
    identity a reverse proxy essentially
  • 00:40:56
    hides the servers Identity or the
  • 00:40:58
    existence of multiple servers behind it
  • 00:41:01
    the client interacts only with the
  • 00:41:03
    reverse proxy and may not know about the
  • 00:41:05
    servers behind it it also distributes
  • 00:41:08
    client requests across multiple servers
  • 00:41:11
    balancing load and ensuring no single
  • 00:41:13
    server becomes overwhelmed reverse proxy
  • 00:41:16
    can also compress inbound and outbound
  • 00:41:19
    data cache files and manage SSL
  • 00:41:21
    encryption there be speeding up load
  • 00:41:23
    time and reducing server load some
  • 00:41:26
    common use case cases of reverse proxies
  • 00:41:28
    are load balancers these distribute
  • 00:41:31
    incoming Network traffic across multiple
  • 00:41:33
    servers ensuring no single server gets
  • 00:41:36
    too much load and by Distributing
  • 00:41:38
    traffic we prevent any single server
  • 00:41:41
    from becoming a bottleneck and it's
  • 00:41:43
    maintaining optimal service speed and
  • 00:41:45
    reliability CDs are also a type of
  • 00:41:48
    reverse proxies they are a network of
  • 00:41:50
    servers that deliver cach static content
  • 00:41:53
    from websites to users based on the
  • 00:41:55
    geographical location of the user they
  • 00:41:58
    act as Reverse proxies by retrieving
  • 00:42:00
    content from the origin server and
  • 00:42:02
    caching it so that it's closer to the
  • 00:42:04
    user for faster delivery another example
  • 00:42:07
    is web application firewalls which are
  • 00:42:10
    positioned in front of web applications
  • 00:42:13
    they inspect incoming traffic to block
  • 00:42:15
    hacking attempts and filter out unwanted
  • 00:42:17
    traffic firewalls also protect the
  • 00:42:20
    application from common web exploits and
  • 00:42:22
    another example is SSL off loading or
  • 00:42:25
    acceleration some reverse proxies handle
  • 00:42:28
    the encryption and decryption of SSL TLS
  • 00:42:31
    traffic offloading that task from web
  • 00:42:33
    servers to optimize their performance
  • 00:42:36
    load balancers are perhaps the most
  • 00:42:38
    popular use cases of proxy servers they
  • 00:42:41
    distribute incoming traffic across
  • 00:42:43
    multiple servers to make sure that no
  • 00:42:45
    server Bears Too Much load by spreading
  • 00:42:48
    the requests effectively they increase
  • 00:42:49
    the capacity and reliability of
  • 00:42:52
    applications here are some common
  • 00:42:54
    strategies and algorithms used in load
  • 00:42:56
    balancing
  • 00:42:57
    first one is round robin which is the
  • 00:42:59
    simplest form of load balancing where
  • 00:43:02
    each server in the pool gets a request
  • 00:43:04
    in sequential rotating order when the
  • 00:43:06
    last server is reached it Loops back to
  • 00:43:08
    the first one this type works well for
  • 00:43:11
    servers with similar specifications and
  • 00:43:14
    when the load is uniformly
  • 00:43:16
    distributable next one is list
  • 00:43:18
    connections algorithm which directs
  • 00:43:20
    traffic to the server with the fewest
  • 00:43:22
    active connections it's ideal for longer
  • 00:43:25
    tasks or when the server load is not
  • 00:43:27
    evenly distributed next we have the
  • 00:43:30
    least response time algorithm which
  • 00:43:32
    chooses the server with the lowest
  • 00:43:34
    response time and fewest active
  • 00:43:36
    connections this is effective and the
  • 00:43:38
    goal is to provide the fastest response
  • 00:43:40
    to requests next algorithm is IP hashing
  • 00:43:44
    which determines which server receives
  • 00:43:46
    the request based on the hash of the
  • 00:43:48
    client's IP address this ensures a
  • 00:43:51
    client consistently connects to the same
  • 00:43:53
    server and it's useful for session
  • 00:43:55
    persistence in application where it's
  • 00:43:57
    important that the client consistently
  • 00:43:59
    connects to the same server the variance
  • 00:44:02
    of these methods can also be vited which
  • 00:44:04
    brings us to the weighted algorithms for
  • 00:44:07
    example in weighted round robin or
  • 00:44:09
    weighted list connections servers are
  • 00:44:11
    assigned weights typically based on
  • 00:44:13
    their capacity or performance metrics
  • 00:44:16
    and the servers which are more capable
  • 00:44:18
    handle the most requests this is
  • 00:44:20
    effective when the servers in the pool
  • 00:44:22
    have different capabilities like
  • 00:44:24
    different CPU or different Rams we also
  • 00:44:27
    have geographical algorithms which
  • 00:44:30
    direct requests to the server
  • 00:44:32
    geographically closest to the user or
  • 00:44:34
    based on specific Regional requirements
  • 00:44:37
    this is useful for Global Services where
  • 00:44:39
    latency reduction is priority and the
  • 00:44:42
    next common algorithm is consistent
  • 00:44:44
    hashing which uses a hash function to
  • 00:44:47
    distribute data across various nodes
  • 00:44:49
    imagine a hash space that forms a circle
  • 00:44:52
    where the end wraps around to the
  • 00:44:54
    beginning often referred to as a has
  • 00:44:56
    ring and both the nodes and the data
  • 00:44:59
    like keys or stored values are hushed
  • 00:45:01
    onto this ring this makes sure that the
  • 00:45:04
    client consistently connects to the same
  • 00:45:06
    server every time an essential feature
  • 00:45:09
    of load balancers is continuous Health
  • 00:45:11
    checking of servers to ensure traffic is
  • 00:45:14
    only directed to servers that are online
  • 00:45:16
    and responsive if a server fails the
  • 00:45:19
    load balancer will stop sending traffic
  • 00:45:22
    to it until it is back online and load
  • 00:45:25
    balancers can be in different forms
  • 00:45:27
    including Hardware applications software
  • 00:45:30
    Solutions and cloud-based Services some
  • 00:45:33
    of the popular Hardware load balancers
  • 00:45:35
    are F5 big IP which is a widely used
  • 00:45:38
    Hardware load balancer known for its
  • 00:45:40
    high performance and extensive feature
  • 00:45:42
    set it offers local traffic management
  • 00:45:45
    Global server load balancing and
  • 00:45:48
    application security another example is
  • 00:45:51
    Citrix forly known as net scaler which
  • 00:45:54
    provides load balancing content
  • 00:45:55
    switching and ation acceleration some
  • 00:45:58
    popular software load balancers are AJ
  • 00:46:01
    proxy which is a popular open-source
  • 00:46:03
    software load balancer and proxy server
  • 00:46:06
    for TCP and HTTP based applications and
  • 00:46:10
    of course Eng X which is often used as a
  • 00:46:12
    web server but it also functions as a
  • 00:46:15
    load balancer and reverse proxy for HTTP
  • 00:46:18
    and other network protocols and some
  • 00:46:20
    popular cloud-based load balancers are
  • 00:46:23
    aws's elastic load balancing or microsof
  • 00:46:27
    oft aure load balancer or Google Cloud's
  • 00:46:30
    load balancer there are even some
  • 00:46:32
    virtual load balancers like Vim ver
  • 00:46:35
    Advanced load balancer which offers a
  • 00:46:37
    softwar defined application delivery
  • 00:46:39
    controller that can be deployed on
  • 00:46:41
    premises or in the cloud now let's see
  • 00:46:44
    what happens when a load balancer goes
  • 00:46:47
    down when the load balancer goes down it
  • 00:46:49
    can impact the whole availability and
  • 00:46:52
    performance of the application or
  • 00:46:54
    Services it manages it's basically a
  • 00:46:57
    single point of failure and in case it
  • 00:46:59
    goes down all of the servers become
  • 00:47:01
    unavailable for the clients to avoid or
  • 00:47:04
    minimize the impact of a load balancer
  • 00:47:06
    failure we have several strategies which
  • 00:47:09
    can be employed first one is
  • 00:47:10
    implementing a redundant load balancing
  • 00:47:13
    by using more than one load balancer
  • 00:47:15
    often in pairs which is a common
  • 00:47:18
    approach if one of them fails the other
  • 00:47:20
    one takes over which is a method known
  • 00:47:22
    as a
  • 00:47:23
    failover next strategy is to
  • 00:47:25
    continuously monitor and do health
  • 00:47:27
    checks of load balancer itself this can
  • 00:47:30
    ensure that any issues are detected
  • 00:47:32
    early and can be addressed before
  • 00:47:35
    causing significant disruption we can
  • 00:47:37
    also Implement Autos scaling and
  • 00:47:39
    selfhealing systems some Modern
  • 00:47:42
    infrastructures are designed to
  • 00:47:43
    automatically detect the failure of load
  • 00:47:45
    balancer and replace it with the new
  • 00:47:47
    instance without manual intervention and
  • 00:47:51
    in some configurations the NS failover
  • 00:47:53
    can reroute traffic away from an IP
  • 00:47:56
    address that is is no longer accepting
  • 00:47:58
    connections like a failed load balancer
  • 00:48:01
    to a preconfigured standby IP which is
  • 00:48:03
    our new load balancer system design
  • 00:48:06
    interviews are incomplete without a deep
  • 00:48:08
    dive into databases in the next few
  • 00:48:10
    minutes I'll take you through the
  • 00:48:12
    database Essentials you need to
  • 00:48:14
    understand to a that interview we'll
  • 00:48:16
    explore the role of databases in system
  • 00:48:18
    design sharding and replication
  • 00:48:20
    techniques and the key ACD properties
  • 00:48:24
    we'll also discuss different types of
  • 00:48:25
    databases vertical and horizontal
  • 00:48:28
    scaling options and database performance
  • 00:48:30
    techniques we have different types of
  • 00:48:32
    databases each designed for specific
  • 00:48:35
    tasks and challenges let's explore them
  • 00:48:38
    first type is relational databases think
  • 00:48:41
    of a relational database like a well
  • 00:48:43
    organized filling cabinet where all the
  • 00:48:45
    files are neatly sorted into different
  • 00:48:47
    drawers and folders some popular
  • 00:48:50
    examples of SQL databases are poster SQL
  • 00:48:53
    MySQL and SQL light all of the SQL
  • 00:48:57
    databases use tables for data storage
  • 00:49:01
    and they use SQL as a query language
  • 00:49:04
    they are great for transactions complex
  • 00:49:06
    queries and integrity relational
  • 00:49:09
    databases are also acid compliant
  • 00:49:11
    meaning they maintain the ACD properties
  • 00:49:14
    a stands for atomicity which means that
  • 00:49:17
    transactions Are All or Nothing C stands
  • 00:49:20
    for consistency which means that after a
  • 00:49:23
    transaction your database should be in a
  • 00:49:25
    consistent state I is isolation which
  • 00:49:28
    means that transactions should be
  • 00:49:30
    independent and D is for durability
  • 00:49:33
    which means that once transaction is
  • 00:49:34
    committed the data is there to stay we
  • 00:49:37
    also have nosql databases which drop the
  • 00:49:40
    consistency property from the ACD
  • 00:49:43
    imagine a nosql database as a
  • 00:49:45
    brainstorming board with sticky notes
  • 00:49:47
    you can add or remove notes in any shape
  • 00:49:50
    of form it's flexible some popular
  • 00:49:52
    examples are mongod DB Cassandra and
  • 00:49:55
    redis there are different different
  • 00:49:56
    types of nosql databases such as key
  • 00:49:59
    value pairs like redis document based
  • 00:50:02
    databases like mongod DB or graph based
  • 00:50:05
    databases like Neo 4G nosql databases
  • 00:50:09
    are schema less meaning they don't have
  • 00:50:11
    foreign Keys between tables which link
  • 00:50:13
    the data together they are good for
  • 00:50:16
    unstructured data ideal for scalability
  • 00:50:19
    quick iteration and simple queries there
  • 00:50:22
    are also inmemory databases this is like
  • 00:50:25
    having a whiteboard for quick
  • 00:50:27
    calculations and temporary sketches it's
  • 00:50:30
    fast because everything is in memory
  • 00:50:32
    some examples are redies and M cach they
  • 00:50:35
    have lightning fast data retrieval and
  • 00:50:37
    are used primarily for caching and
  • 00:50:39
    session storage now let's see how we can
  • 00:50:42
    scale databases the first option is
  • 00:50:44
    vertical scaling or scale up in vertical
  • 00:50:47
    scaling you improve the performance of
  • 00:50:49
    your database by enhancing the
  • 00:50:51
    capabilities of individual server where
  • 00:50:54
    the data is running this could involve
  • 00:50:56
    increasing CPU power adding more RAM
  • 00:50:59
    adding faster or more dis storage or
  • 00:51:01
    upgrading the network but there is a
  • 00:51:03
    maximum limit to the resources you can
  • 00:51:05
    add to a single machine and because of
  • 00:51:08
    that it's very limited the next option
  • 00:51:10
    is horizontal scaling or scale out which
  • 00:51:13
    involves adding more machines to the
  • 00:51:15
    existing pool of resources rather than
  • 00:51:17
    upgrading the single unit databases that
  • 00:51:20
    support horizontal scaling distribute
  • 00:51:22
    data across a cluster of machines this
  • 00:51:25
    could involve database sharding or data
  • 00:51:27
    replication the first option is database
  • 00:51:30
    sharding which is Distributing different
  • 00:51:32
    portions shards of the data set across
  • 00:51:34
    multiple servers this means you split
  • 00:51:37
    the data into smaller chunks and
  • 00:51:39
    distribute it across multiple servers
  • 00:51:41
    some of the sharding strategies include
  • 00:51:44
    range based sharding where you
  • 00:51:46
    distribute data based on the range of a
  • 00:51:48
    given key directory based sharding which
  • 00:51:51
    is utilizing a lookup service to direct
  • 00:51:53
    traffic to the correct database we also
  • 00:51:56
    have geographical charting which is
  • 00:51:58
    splitting databases based on
  • 00:52:00
    geographical
  • 00:52:01
    locations and the next horizontal
  • 00:52:03
    scaling option is data replication this
  • 00:52:06
    is keeping copies of data on multiple
  • 00:52:08
    servers for high availability we have
  • 00:52:11
    Master Slave replication which is where
  • 00:52:14
    you have one master database and several
  • 00:52:16
    read only slave databases or you can
  • 00:52:19
    have master master application which is
  • 00:52:22
    multiple databases that can both read
  • 00:52:24
    and write scaling your data database is
  • 00:52:27
    one thing but you also want to access it
  • 00:52:29
    faster so let's talk about different
  • 00:52:31
    performance techniques that can help to
  • 00:52:33
    access your data faster the most obvious
  • 00:52:36
    one is caching caching isn't just for
  • 00:52:39
    web servers database caching can be done
  • 00:52:41
    through inmemory databases like redies
  • 00:52:44
    you can use it to cat frequent queries
  • 00:52:46
    and boost your performance the next
  • 00:52:48
    technique is indexing indexes are
  • 00:52:50
    another way to boost the performance of
  • 00:52:52
    your database creating an index for
  • 00:52:55
    frequently accessed column will
  • 00:52:56
    significantly speed up retrieval times
  • 00:52:59
    and the next technique is query
  • 00:53:01
    optimization you can also consider
  • 00:53:03
    optimizing queries for fast data access
  • 00:53:05
    this includes minimizing joints and
  • 00:53:07
    using tools like SQL query analyzer or
  • 00:53:10
    explain plan to understand your query's
  • 00:53:13
    performance in all cases you should
  • 00:53:15
    remember the cap theorem which states
  • 00:53:17
    that you can only have two of these
  • 00:53:19
    three consistency availability and
  • 00:53:21
    partition tolerance when designing a
  • 00:53:24
    system you should prioritize two of the
  • 00:53:26
    is based on the requirements that you
  • 00:53:28
    have given in the interview if you
  • 00:53:30
    enjoyed this crash course then consider
  • 00:53:32
    watching my other videos about system
  • 00:53:34
    Design Concepts and interviews see you
  • 00:53:36
    next time
Tags
  • system design
  • scalability
  • high-level architecture
  • load balancing
  • caching
  • networking
  • API design
  • CAP theorem
  • databases
  • proxy servers