VIDEO
HIGHLIGHT
Log InSign up
ABH-0001-Foundational Topics in SD 1
SummaryTranscriptChat

ABH-0001-Foundational Topics in SD 1

Introduction

The instructor introduces the course and explains how it will be structured.

Course Structure

  • The sessions will be recorded and uploaded to a Google Drive after completion.
  • The instructor is building a product to help manage code better.
  • Lifetime content will be accessible through another link.
  • Random talks from industry experts may be held over weekends.

System Design Overview

The instructor provides an overview of the course and encourages active participation.

Course Expectations

  • Participants should speak up, participate, and ask questions.
  • Participants should take notes on new terms and revise them later.
  • Participants should ask for one-on-one help if needed.
  • There will not be direct assignments, but participants should implement certain things pointed out by the instructor.

Active Participation

  • Active participation is encouraged, including speaking up and asking questions.
  • Questions are helpful for everyone in the class.
  • The course is non-repetitive, so revision is important for recall in future weeks.

Instructor Availability

  • The instructor can be messaged on Discord or email for one-on-one help.
  • Slots are wide open but need to be scheduled a day prior due to time constraints.

Introduction and Course Overview

The instructor introduces the course and provides an overview of what students can expect to learn.

Course Expectations

  • Students are expected to understand the system from end-to-end from an engineering perspective.
  • Students should be willing to participate, share articles or videos on Discord, and ask questions.
  • The course is designed for a long-term approach to learning about systems, not just mastering it in two months.
  • Feedback is important and will be collected after each lecture.

Logistics and Resources

The instructor discusses logistics for the course, including how resources will be shared with students.

Logistics

  • Calendar invites were sent out but if anyone did not receive one, they can check Google Groups or Discord for updates.
  • Notes and resources will be uploaded to Google Drive after each session.
  • Feedback forms will be shared after each lecture.

Foundational Take on System Design

The instructor begins discussing foundational concepts of system design.

Key Points

  • This section covers the most common thing found when searching for system design online.
  • It lays the foundation for understanding how real systems are built.

What is System Design?

In this section, the speaker explains what system design is and its different types.

Types of System Design

  • True system design involves building an application, module or service.
  • Independent microservices architecture and massive architectures like Instagram fall under system design.
  • Low-level component interactions, throttling, retrying and configuration management are also part of system design.
  • Applications such as web and mobile applications are included in the spectrum of product development.

Different Types of Design

In this section, the speaker discusses different types of designs including architectural design and logical system design.

Architectural Design

  • Architectural design refers to how a system looks from a bird's eye view.
  • It involves understanding how requests come in, load balancing, backend servers connected to databases with caches in front.

Logical System Design

  • Logical system design focuses on logics, algorithms and business logic.
  • Business logic is critical because it ensures that features can keep changing while underlying infrastructure systems remain robust enough to scale up over time.
  • Extensibility is important while designing any system. A layer of abstraction or DAO layer comes in handy when changing database providers from SQL to NoSQL.

The Importance of Business Requirements

In this section, the speaker emphasizes the importance of prioritizing business requirements over engineering efforts.

Balancing Engineering and Business Needs

  • Engineers must prioritize business needs over their desire to write efficient code or build the best system.
  • Sometimes engineers have to succumb to business requirements, even if it means writing bad code or doing bad design.
  • It's important to keep in mind that a business has to survive for an engineer's job to exist.

Building Extensible Systems

In this section, the speaker discusses how engineers can balance building the best system with making it extensible for future changes.

Designing for Extensibility

  • When possible, engineers should strive to build the best system from an architecture point of view that is also extensible.
  • This involves handling scale on a lower level by applying optimal locking mechanisms and modeling systems in a way that supports abstractions.
  • However, premature optimization can be detrimental and engineers should only focus on low-level optimizations when they have enough time.

Logical Design vs. Architectural Design

  • Logical design is more abstracted than architectural design because it needs to be extensible.
  • If you change your database provider, you would need to go through an entire business logic if all queries are written in one big file. But if you have a separate abstracted layer in front of it which makes all the database queries, then changing providers becomes easier.

Avoiding Strong Coupling Between Systems

In this section, the speaker emphasizes the importance of avoiding strong coupling between systems to ensure flexibility and scalability.

Importance of Abstractions

  • Low-level design must support abstractions needed by high-level design to avoid creating a strong coupling to a certain provider.
  • For example, if all your code is written for AWS services and they increase their prices, it would be difficult to migrate to another cloud provider if your low-level code is not abstracted enough.

Payment Gateway Example

  • Payment gateway integration is a good example of how abstraction can help. If you need Stripe and then decide to switch to another payment gateway, you would have to abstract it out.

Payment Gateway Options

This section discusses the importance of payment gateway options and how companies need to be prepared for unexpected changes.

Importance of Payment Gateway Options

  • Within a day, all companies had to move to a different payment gateway option.
  • Yes Bank and Paytm faced this issue about a year ago.
  • If low-level code is not expected enough, migration time can be much higher.
  • Business priorities often prioritize execution over abstraction.

Parallel Designing

This section discusses the challenges of parallel designing and how it doesn't always go as planned.

Challenges of Parallel Designing

  • Business priorities often prioritize execution over abstraction.
  • Typically, business, architecture, and low-level design should go in parallel but that's not always the case.

Physical Designing

This section discusses physical designing with respect to cloud computing.

Physical Designing for Cloud Computing

  • Input/output interfaces storage needs to be considered when designing for cloud computing.
  • Capacity planning is important when deciding how many servers are required to handle traffic.
  • DevOps teams configure auto-scaling policies based on incoming traffic and expected response times.
  • Back-of-the-envelope calculations come in handy when making good decisions regarding hardware requirements.

High-Level View of Systems

In this section, the speakers discuss the high-level view of a system and mention physical design as the most important aspect for scalability. They also talk about how cloud providers like AWS have changed the game for startups.

Importance of Physical Design

  • Physical design is crucial for scalability.
  • AWS has solved most scalability problems in recent years.
  • Instagram had 14 million users with only three engineers managing it because they were cloud-native.

Challenges with On-Premise Infrastructure

  • Physical infrastructure is needed on the backend to process and create software-defined solutions.
  • Most servers currently use one gig, and even 10 gig nics are not very famous yet.

Admired Engineering Systems

The speakers discuss their favorite engineering systems and why they admire them. They mention Cred, Cultivate, Thundering Herd, Massive Space, and YouTube.

Cred and Cultivate

  • Cred and Cultivate have done an excellent job at handling scale.

Thundering Herd and Massive Space

  • Thundering Herd has many players that need to sync up, making it a marvel.
  • No further information provided about Massive Space.

YouTube

  • No specific timestamp provided for this topic. The speakers discuss how YouTube handles scale by improving their system when Gangnam Style broke it and creating YouTube Shorts when TikTok started rising to fame.

Understanding System Architecture

In this section, the speaker talks about how YouTube and WhatsApp are dependent on other variants. They also discuss the importance of reading blogs to gain insights into how engineering is driven in these companies.

Dependence on Variants

  • YouTube is a system that the speaker admires for its gigantic amount of data storage.
  • Products like PUBG are dependent on many other variants, and from what the speaker knows, Zero does not use cloud because they need to maintain latency and be on-prem.
  • Dream 11's challenge is that it is cloud-native and heavily reliant on AWS for scaling.

Reading Blogs for Insights

  • The speaker recommends reading blogs from companies like YouTube and WhatsApp to gain insights into how their engineering is driven.
  • Sebi has shared an architecture for building your own discount brokerage company, which can be found on their official website.
  • The CT of Zero came on a series discussing RK systems architecture, giving a detailed bird's eye view of how Zero functions.

Amazon's Scale and Prediction Engines

In this section, the speaker talks about Amazon's scale during Prime Day and Cyber Monday/Black Friday sales. They also discuss Amazon's prediction engines and how they handle large amounts of data.

Scale During Sales

  • During Prime Day, Amazon handled an amazing amount of requests through services like DynamoDB and SQS.
  • During Cyber Monday/Black Friday sales, the speaker was blown away by the prediction engine at Amazon that had a permanent prediction of how many orders would be placed with a certain level of confidence.

Handling Large Amounts of Data

  • The speaker wonders how much data Amazon would have required to predict accuracy in this minute and how they handle that much amount of concurrency.
  • Amazon relies on various other competitions for themselves in the market, such as CDN issues.

Hacking and System Security

In this section, the speaker talks about their experience with hacking and system security. They discuss how companies face engineering challenges while building systems and the importance of defining a scope for any system.

Experience with Hacking

  • The speaker talks about an app called Up Stock that was hacked, and its details were put online for sale.
  • The speaker shares their personal experience of being part of a team that had to flip their entire infrastructure after their company was hacked.
  • Technical data was out of the blue curve wrote it, every single DC to instance, every single SQL databases were changed because data was compromised.

Importance of Defining Scope

  • It is important to define a scope when designing any system so that you can roll out your product without constantly adding new features.
  • Functional scope refers to the features end-users would use, while non-functional scope refers to engineering aspects such as speed, reliability, and security.
  • Critical questions should be asked during the design process to course-correct the direction of your product.

Conclusion

In this section, the speaker concludes by encouraging listeners to read and explore more about building great systems.

Building Great Systems

  • The speaker encourages listeners to read and consume knowledge wealth available on building great systems.
  • Curiosity is key in igniting interest in building great systems.
  • When approaching system design, it's important to define both functional and non-functional scopes.
  • The speaker concludes by encouraging listeners to ask critical questions and change the direction of their product if necessary.

Designing a System from Scratch

In this section, the speaker discusses how to design a system from scratch and the importance of seeking clarifications.

Seeking Clarifications

  • When designing a system from scratch, there is often ambiguity that needs to be addressed.
  • Picking one technology over another needs to be a conscious decision made with extensibility in mind.
  • It's important to seek clarifications on requirements and clarity before making decisions.

Bottom-Up vs Incremental Approach

  • Building systems typically comes in two flavors: bottom-up or incremental.
  • Big companies tend to go for the bottom-up approach while startups should go for an incremental approach.
  • Both approaches are okay depending on the work environment or situation.

Defining Building Blocks

  • Defining building blocks for your system involves defining relationships between components and how they communicate with each other.
  • Communication can occur through HTTP, shared databases, or message brokers.
  • Identifying bottlenecks is important so you can anticipate when your system will not scale well.

Monolith vs Microservices

In this section, the speaker discusses whether to start with monolith or microservices when building from scratch.

Starting Small and Building on Top

  • Always start small and build on top of it.
  • You should not aim for a great system from day one but have a vision in mind for at least two hops in the future so that your system is extensible for the next level of scale.

Monolith vs Microservices

  • When starting from scratch, it's better to start with a monolith and then move towards microservices as the system grows.
  • Microservices are good for scaling but come with added complexity.

Importance of Time to Market

In this section, the speaker discusses the importance of time to market and whether to build a monolith or microservices.

Monolith vs Microservices

  • Building microservices from day one is not recommended as it is uncertain if the product will survive. Instagram started with a monolith and had 14 million users in one year.
  • If working at Amazon, building services from day one is necessary. However, for startups building something from scratch, it's better to start with a monolith and then move on to microservices later.
  • It's important to consider future uncertainty when deciding between a monolith or microservices. Moving from a monolith to microservices can be difficult once users are already using the product.

Designing a Personal Blog

In this section, the speaker discusses designing a personal blog and the basic requirements needed.

Basic Requirements

  • The personal blog should have multiple posts with tags that allow readers to browse by tag.
  • There should be a search bar that enables readers to find an article.
  • Blogs should be ordered by time and support one million concurrent readers.
  • The blog should be available 99.9999% of the time and load fast.

Six Components of Any System

The six components that need consideration while designing any system are:

Database

A persistent layer where data can be stored.

Caching

Caching helps improve performance by storing frequently accessed data in memory.

Scaling

Scaling can either be horizontal or vertical depending on the needs of the system.

Delegation

Delegation is an underrated way of gaining performance out of your system. It involves delegating workloads to other systems or services.

Concurrency

Concurrency refers to how many requests can be processed simultaneously without affecting performance.

Communication

Communication refers to how different components of the system communicate with each other.

Concurrency and Communication

This section discusses how to handle concurrency and communication in a system.

Handling Concurrent Users

  • Mutex is used for locking to protect critical sections.
  • Communication can be over HTTP, but there are many other options such as gRPC, web sockets, raw TCP, or UDP.
  • The choice of communication protocol can impact system scaling and performance.

Database Options

  • In-memory databases cache data in memory while disk-based databases store data on disk. Examples include MySQL and MongoDB.
  • Server databases have their own server to run, such as MySQL servers or MongoDB servers.
  • Embedded databases run within the context of the application and do not have a separate server running.
  • Row-based databases structure data by rows while columnar databases structure data by columns.
  • Graph databases model graph relationships between objects.
  • Time series databases are used for handling time series data with time on one axis and metrics on another axis.
  • Relational and non-relational SQL/NoSQL databases exist along with blob storages like S3 that store binary long objects. Flat file storages store flat files.

List of Databases

This section lists various types of databases.

Types of Databases

  • In-memory
  • Disk-based (MySQL, MongoDB)
  • Server (MySQL server, MongoDB server)
  • Embedded
  • Row-based
  • Columnar
  • Graph
  • Time series
  • Relational/non-relational SQL/NoSQL
  • Blob storage (S3)
  • Flat file storage

Types of Databases and their Optimal Use

In this section, the speaker discusses different types of databases and their optimal use for certain businesses.

Types of Databases

  • Different types of databases can be used to design a blog, such as in-memory databases, embedded databases, columnar storage, and time series databases.
  • Each type of database is optimal for a certain kind of business. It's important to be aware of these options when making a choice.
  • Time series data can be used to build a blog on top of the data.

Modeling Time Series Data

  • Every database has a different way of storing data. For example, time series data can be modeled on traditional databases like MySQL or Postgres using TimescaleDB. However, this might not be the most optimal way to do so compared to using dedicated time series databases like InfluxDB or Prometheus.
  • You can model any type of database on top of any other database that is available in the list. However, it may not always be the most efficient method. For instance, you can model columnar storage on non-relational databases or graph databases on SQL storage or MongoDB.

Storage vs Database

  • The speaker argues that storage should not be considered part of a database because they are different classes altogether.
  • S3 stores object data while granular data is stored in a database.
  • While S3 could act as a database by modeling it as such with user IDs becoming directories and blog post IDs becoming files within those directories, it does not offer query language capabilities like traditional databases do.

S3 vs Databases

In this section, the speaker discusses the differences between S3 and databases.

S3 as a Database

  • S3 is similar to Microsoft Azure storage and does not offer query language capabilities like traditional databases.
  • The granularity of data stored in S3 is at the object level, while databases store granular data.

Querying from S3 with Athena

In this section, the speaker discusses using Athena to query data from S3 and how it can be used to get similar data in the form of a table.

Using Athena for querying S3

  • Athena can be used to query data from S3.
  • The lines between different storage classes are getting blurry as databases evolve.
  • Every database is trying to be every other database.

Choosing a Database for a Blog

In this section, the speaker discusses choosing a database for a blog and why starting with SQL is often the most common choice.

Choosing a Database

  • Starting with SQL is often the most common choice because it's easily translatable into any other NoSQL way.
  • It's important to think about the attributes of entities when modeling tables.
  • There is no one way to design a system; every system can be designed in hundreds of ways.
  • You can start with any approach, such as databases or APIs.

Designing Tables for a Blog

In this section, the speaker discusses designing tables for a blog and what fields should be included in each table.

Table Design

  • A user table should have id, name, and bio fields.
  • A blog table should have id, title, user_id (for author), published date, body text, excerpt (short summary), slug (URL-friendly version of title), and deleted fields.

Soft Delete vs Hard Delete

This section discusses the advantages of using soft delete over hard delete in a database.

Soft Delete vs Hard Delete

  • Soft delete is useful for recovery, archives, and reference purposes.
  • If you want to recover deleted data, use soft delete with a timestamp.
  • Auditing also requires a timestamp for soft deletes.
  • Use hard delete if you don't want your data to be recoverable.
  • Hard deletes can negatively impact database performance due to disk I/O and fragmentation.
  • Perform hard deletes in batches during low traffic periods to optimize performance.

Storing Blog Body in Database

This section discusses whether or not it's advisable to store the body of a blog post in a database table.

Storing Blog Body

  • It's not advisable to store the body of a blog post in the same table as other metadata due to its size.
  • The first 1024 characters could be stored in the same table for search purposes.
  • Consider using blob storage instead.

Storing Blog Body in Database

In this section, the speaker discusses how to store blog body in a database and calculates the storage required for an average length of 5000 words.

Storing Blog Body in Database

  • It is not a big thing to store the body of the blog in the database because it is never going to be that massive.
  • An average length of a word is five characters and each character takes four bytes of storage if we are going for utf mb encoding. If we have 5000 words, then about 100kb of storage would be required to store this much data.
  • The database engine should not have any problem storing this much data in one row.

Storing Images and Collaborative Documents

In this section, the speaker discusses how to store images and collaborative documents.

Storing Images and Collaborative Documents

  • If we want to store images of megabytes that are being updated constantly, we should consider moving them out to a different storage altogether.
  • For collaborative documents like Google Docs where multiple people are updating it, moving it out to a different storage altogether would make sense.
  • For simple blogs where once published, minor updates would be done here or there, storing body in table makes sense.

Cross Referencing Feature Implementation

In this section, the speaker discusses how implementing cross-referencing as a feature would impact design.

Cross Referencing Feature Implementation

  • Implementing cross-referencing as a feature could impact design, and the speaker will cover this later.
  • When iterating through all the blocks of a table, if a very massive body or structure is stored in a block, like an image, then the database would have to perform disk I/O of that much chunk before moving to the next location.

Understanding the Impact of Row Size on Database Performance

In this section, the speaker discusses how row size can impact database performance and how to optimize row design.

Optimizing Row Design

  • Discarding unnecessary columns can improve performance.
  • Indexing can help with lookups but may not be optimal for large rows.
  • Storing bulkier objects in a row can negatively impact performance.

How Indexes May Not Help

  • If a single row is too long, indexing may not help with performance.
  • When iterating sequentially through a large page, it's the worst thing you can do to your database.

Choosing Column Types

  • Choosing column types like long text or varchar can affect how data is stored in rows and impact performance.
  • Long text is stored as a reference to another location, making rows leaner and more efficient.

Storing Data in JSON Format

This section discusses the benefits of storing data in JSON format and how it can be stored in a database.

Storing Data in JSON Format

  • Storing data in JSON format in a database row allows for easy retrieval and manipulation of the data.
  • While NoSQL storage can be used directly, Postgres SQL is preferred due to its support system.
  • Performance depends on how the end user experience is designed, as loading large amounts of data at once can slow down performance.

Storing Images

  • Images are stored separately from text using blob storage meant for this purpose.
  • A URL of the image is stored in the database to keep rows leaner and avoid performance issues.

Benefits of Using Tag IDs

This section discusses the benefits of using tag IDs instead of raw tag strings when storing tags.

Using Tag IDs

  • Tags are separated into two tables: one for all unique tags and another for mapping between blog ID and tag ID.
  • Using tag IDs instead of raw tag strings saves space and improves performance by allowing for faster integer comparisons.
  • The disadvantage is that joins are required to access both blog information and corresponding tag names.

Advantages of Tag IDs

  • Same tags can be used for multiple blocks, saving space.
  • Changing tag names does not affect the system since only the ID needs to be updated.

Adding Abstraction to a Database

In this section, the speaker discusses adding abstraction to a database and how it can help with normalization.

Abstraction in Databases

  • Adding abstraction to a database can help with normalization.
  • Renaming tags, categories, and similar items becomes easier with added abstraction.

Normalizing a Database

This section covers the process of normalizing a database and the trade-offs involved.

Reducing Redundancy

  • Normalizing a database helps reduce redundancy.
  • However, this can lead to increased joint operations which can be expensive.
  • SQL servers are designed to handle joints efficiently but they still have some cost associated with them.

Giving Up on Normalization for Performance

  • At scale, it may be necessary to give up on full normalization for performance reasons.
  • While fully normalized databases adhering to 3NF are best practice, sometimes performance needs outweigh design principles.

Storing Dates in Databases

This section covers storing dates in databases and the benefits of using integers over datetime objects.

Choosing Data Types

  • When designing a database schema, you typically choose between datetime or an integer like epoch seconds.
  • Epoch seconds are faster for range queries as CPUs are optimized for processing numbers efficiently.

Benefits of Integers Over Datetime Objects

  • Storing epoch seconds or milliseconds is much faster than storing datetime objects as it avoids serialization and unmarshalling overhead.
  • Range queries become more efficient when using integers instead of datetime objects.

Using YYMMDD Format

  • Storing dates as YYMMDD integers provides both human readability at the database level and power for integer comparisons.
  • Queries on date ranges become possible while still maintaining human readability.

Handling Time Zones in a System

In this section, the speaker discusses how to handle time zones in a system.

Storing Time Zones

  • Store time zones as ISO strings or epoch.
  • Always convert everything to UTC and store it.
  • Tenantize the entire system if possible.

Front-end vs Back-end

  • Handle time zones on the front-end side.
  • Work on UTC from the back-end side.

Impact of Small Decisions

  • Small decisions like storing time zone aware strings can have a massive impact on database performance.

High-Level Architecture for a System

In this section, the speaker discusses the high-level architecture for a system.

User and Database

  • The high-level architecture consists of users and databases.

API Server

  • The API server acts as a middleman between the user and database.
  • The API server handles business logic such as authorization checks, authentication, post-processing, filtering results, etc.

REST API Designing

  • When designing REST APIs or building microservices communication, consider using gRPC or raw phase protocols.

Search Box Requirements for a System

In this section, the speaker discusses search box requirements for a system.

Search Box Functionality

  • A search box should be able to handle complex queries with multiple filters.
  • The search box should be able to handle large amounts of data.
  • The search box should have a fast response time.

Search Box Implementation

  • Implement the search box using Elasticsearch or Solr.
  • Use indexing and caching to improve performance.

Overview of Elasticsearch and Database

In this section, the speaker discusses how Elasticsearch is used for fuzzy searching and why it's important to use specialized databases for certain tasks.

Elasticsearch and Fuzzy Searching

  • Elasticsearch is a specialized database that stores data in a format that makes it efficient for fuzzy searching.
  • It's important to keep data in sync between the main database and Elasticsearch by writing updates to both places.
  • Using the right set of tools to solve specific problems is crucial. For example, MySQL is not meant for string matching like Elasticsearch.

How Elasticsearch Works

  • When using Elasticsearch for fuzzy search, it matches text by returning all sentences that belong to a particular text.
  • The way data is stored in Elasticsearch is different from SQL storage because you want to structure the data optimally for searching with Elasticsearch. This requires denormalizing the data and storing it in a certain format.

Syncing Data Between Databases

  • Syncing data between databases can be done through a separate service or API that transforms updates into a format optimal for each database.
  • Storing data in two places (main database and Elasticsearch) allows you to choose the best tool for each task, rather than being limited by one type of database. However, this may not always be necessary depending on your use case.

Introduction to the Problem

In this section, the speaker introduces a problem faced by an e-commerce company that needs to provide search functionality on top of its payment system. The speaker discusses how specialized systems can be used to handle different use cases.

Providing Search on Top of Payment System

  • An e-commerce company needs to provide search functionality on top of its payment system.
  • Elasticsearch is efficient for fuzzy queries, but SQL databases need to be ACID compliant.
  • Specialized systems are needed for handling payments and search functionalities.
  • Different use cases require different systems.

Designing a Blog Database

In this section, the speakers discuss how designing a blog database would differ from designing a database for a multi-user system. They also talk about using Elasticsearch instead of MySQL for simple systems like blogs.

Designing for Single User Systems

  • For single user systems like blogs, Elasticsearch can be used instead of MySQL.
  • Caching can make reads more efficient in write-once-read-many use cases.
  • All design decisions should be based on critical questions like why not just use Elasticsearch?

Applying Caching in Blog Application

  • Caches exist at all levels in the architecture and help reduce expensive operations.
  • Spend time thinking about all possible places where caching can be applied in a blog application.
  • Cache hits are good and cache misses are costly.

Conclusion

In this section, the speaker concludes by summarizing key points discussed throughout the video.

Key Takeaways

  • Specialized systems are needed for handling different use cases.
  • Different design decisions should be based on critical questions like why not just use Elasticsearch?
  • Caching can make reads more efficient in write-once-read-many use cases.

Caching Strategies

In this section, the speaker discusses different caching strategies that can be used to optimize performance.

Application Server Cache

  • The application server cache is an underrated way to optimize performance.
  • It involves caching data on the API server itself, rather than relying on a central cache like Redis or Memcached.
  • Request layer caching is a type of application server cache where caching happens on the API server.

Central and Distributed Cache

  • A central cache is optimal for most cases, but a distributed cache comes in handy when a single cash node is not able to handle the load.
  • Scaling a central cache into multiple clusters can help handle traffic.
  • Redis offers services for creating and managing distributed caches.

CDN Level Caching

  • CDN level caching involves caching static data like images across geography so that requests don't have to flow to the origin server every time.
  • This helps improve performance for users accessing content from different parts of the world.