What is system?

System is the set of technologies which serve some users to fill set of requirement.

What is design?

"design" refers to the process of creating a detailed plan or blueprint for how the system will
be structured and how its components will work together to achieve the desired goals.

What is system design?

System design is the process of designing the element of the system such as the architecture,
modules and components, the different interfaces of those components and the data that goes
through the system.

Types of system design

HLD high level design Low level design LLD

Describe the main component that would be Describe the design of each element men oned
developed for the final product. in the HLD of the system.
System architecture details, database design, Classes, interfaces, rela onships between
services and processes, the rela onship different classes, and actual logic of the various
between various modules and features. components.
Or Physical design, logical design and
architecture.

Architecture design -> Service / Architecture / Modules.

Logical design -> Communica on / API.

Physical design -> Data-processing / Storage.

Why system design?

 Reliable: Fault tolerant, handle failures.

 Effec ve: Meet the business requirement.
 Maintainable: Flexible to scale up/down, Code’s maintainable.

Func onal requirement for twi er Non-Func onal requirement for twi er
Post tweet, like tweet, follow, unfollow and etc. Reliable, highly available, security, consistent
and low latency.

Architecture:

Internal design details for building the applica ons.

Monolithic architecture: it is the approach in which front-end, back-end and database of an web
applica on are wri en as a single unit or in a single codebase.
  There is only a single codebase.
 Monolithic system is also known as centralized system.

Advantages:

When we are just star ng.

 In monothe c architecture, all the modules are present in the single system, so they require
fewer network calls.
 Integra on tes ng is easier.
 Less confusion.

Disadvantage:

 If there is a bug in the single module it can destroy the whole system.
 Whenever a single module is updated, the whole system needs to be updated to reflect the
changes to the users.

Distributed System
 A distributed system is a collec on of mul ple individual system connected through a
network that shares resources, communicate, and coordinate to achieve common goals.
 Modules are present in different codebase and they connected through a network that
shares resources, they communicate and coordinate to achieve common goals.

Advantages:

 Scalable.
 Low latency.
 No single point of failure.

Disadvantages:

 Complex due to mul ple server

 Management req.
 Difficult to secure

Monothe c latency: computa onal delay.

Distributed latency: computa onal delay+ network delay.

Scalability
Increasing the performance of system by handling large number of transac on or serving
more unit of work.
A service is said to be scalable if when we increase the resources in a system, it results in
increased performance in a manner proportional to resources added. Increasing
performance in general means serving more units of work, but it can also be to handle larger
units of work, such as when datasets grow. Introducing redundancy is an important for
defending against failures. An always-on service is said to be scalable if adding resources
to facilitate redundancy does not result in a loss of performance.

A second problem area is heterogeneity, resources added in the system increase in

diversity some resources are of next generation and they are powerful. Heterogeneity means
that some nodes will be able to process faster or store more data than other nodes in a
system and algorithms that rely on uniformity either break down under these conditions or
underutilize the newer resources.
For the systems we build we must carefully inspect along which axis we expect the system
to grow, where redundancy is required, and how one should handle heterogeneity in this
system
Performance vs Scalability

Performance measures how quickly it can process a given set of operations.

Scalability measures ability of a system to handle increasing amounts of work or users

without a significant decrease in performance.

Another way to look at performance vs scalability:

 If you have a performance problem, your system is slow for a single user.
 If you have a scalability problem, your system is fast for a single user but slow
under heavy load.

Latency vs throughput
 Latency is the time to perform some action or to produce some result.
 Throughput is the number of such actions or results per unit of time.
 Generally, you should aim for maximal throughput with acceptable latency.

What is latency (technically)?

It is Network delay + Computa onal delay.

Time taken by request to reach server + Time taken to process request + Time to return response to user

T1

user Server
T2

T3
The following manufacturing example should clarify these two concepts:

An assembly line is manufacturing cars. It takes eight hours to manufacture a car and that
the factory produces one hundred and twenty cars per day.

The latency is: 8 hours.

The throughput is: 120 cars / day or 5 cars / hour.

CAP theorem

CAP theorem states it is impossible for a distributed system to simultaneously

guarantee three properties: Consistency, Availability, and Partition tolerance.

Here's a simple explanation of each property:

1. Consistency: All nodes in the distributed system have the same data at the
same time. In other words, when a change is made to one part of the system,
all other parts immediately see that change.
2. Availability: Every request made to the system gets a response, either
successful or failed. The system is always up and operational, providing timely
responses to client requests.
3. Partition tolerance: The system continues to function even if network
communication between nodes is unreliable or completely breaks down. This
means the system can handle and recover from network failures and splits.

According to CAP theorem, a distributed system can prioritize two of these

properties but not all three simultaneously. In practical scenarios, most distributed
systems tend to focus on either Consistency and Availability (CA systems) or
Availability and Partition tolerance (AP systems). Sacrificing Consistency for greater
Availability and Partition tolerance is a common choice in many real-world systems.

Consistency patterns
With multiple copies of the same data, we are faced with options on how to
synchronize them so clients have a consistent view of the data. Recall the definition
of consistency from the CAP theorem - Every read receives the most recent write or
an error.
Weak consistency

After a write, reads may or may not see it. A best effort approach is taken.

This approach is seen in systems such as Memcached. Weak consistency works well
in real time use cases such as VoIP, video chat, and real-time multiplayer games. For
example, if you are on a phone call and lose reception for a few seconds, when you
regain connection, you do not hear what was spoken during connection loss.

Weak consistency is suitable for use cases where high availability and low-latency
access are critical, and occasional data conflicts can be tolerated.

Eventual consistency
Eventual consistency is a consistency model that allows data replicas in a distributed
system to become consistent over time without the need for immediate
synchronization

This approach is seen in systems such as DNS and email. Eventual consistency works
well in highly available systems.

Strong Consistency

Strong consistency is the strongest and most rigid consistency model. It ensures that
all read operations return the most recent write, and all replicas remain consistent at
all times.

Data is replicated synchronously. This approach is seen in file systems and RDBMS.
Strong consistency works well in systems that need transactions.

Availability patterns
There are two complementary patterns to support high availability:

fail-over and replication (Master-slave and master-master).

1. High availability through failover:

Failover is the transfer of workload from a primary system to a secondary system in

the event of a failure on the primary system. When workload has been transferred
like this, the secondary system is said to have taken over the workload of the failed
primary system.
Example 1

In a clustered environment, if one machine in the cluster fails, cluster managing

software can move processes that were running on the machine that failed to
another machine in the cluster.

Example 2

In a database solution with multiple IBM® Data Servers, if one database becomes
unavailable, the database manager can reroute database applications that were
connected to the database server that is no longer available to a secondary
database server.

The two most common failover strategies on the market are known as idle standby
and mutual takeover:

Idle Standby

In this configuration, a primary system processes all the workload while a

secondary or standby system is idle, or in standby mode, ready to take over the
workload if there is a failure on the primary system. In an high availability
disaster recovery (HADR) setup, you can have up to three.

Mutual Takeover

In this configuration, there are multiple systems, and each system is the
designated/appoint secondary for another system. When a system fails, the
secondary for the system that failed must continue to process its own workload
as well as the workload of the failed system.

2. Replica on

Master-slave replication

The master serves reads and writes, replicating writes to one or more slaves, which
serve only reads. Slaves can also replicate to additional slaves in a tree-like fashion. If
the master goes offline, the system can continue to operate in read-only mode until
a slave is promoted to a master or a new master is provisioned.
Disadvantage Master-slave Replication

 Additional logic is needed to promote a slave to a master.

Master-Master replication

Both masters serve reads and writes and coordinate with each other on writes. If
either master goes down, the system can continue to operate with both reads and
writes.

Disadvantages of Master-Master replica on

 You'll need a load balancer or you'll need to make changes to your application
logic to determine where to write.
 Most master-master systems are either loosely consistent (violating ACID) or
have increased write latency due to synchronization.
 Conflict resolution comes more into play as more write nodes are added and
as latency increases.
Disadvantage(s): replication both master-master and master-slave.

 There is a potential for loss of data if the master fails before any newly written data
can be replicated to other nodes.
 Writes are replayed to the read replicas. If there are a lot of writes, the read replicas
can get bogged down with replaying writes and can't do as many reads.
 The more read slaves, the more you have to replicate, which leads to greater
replication lag.
 On some systems, writing to the master can spawn multiple threads to write in
parallel, whereas read replicas only support writing sequentially with a single thread.
 Replication adds more hardware and additional complexity.

Availability in numbers

Availability is often quantified by uptime (or downtime) as a percentage of time the

service is available. Availability is generally measured in number of 9s--a service with
99.99% availability is described as having four 9s.

Availability in Sequence vs Parallel

If a service consists of multiple components prone to failure, the service's overall

availability depends on whether the components are in sequence or in parallel.
Sequence

Overall availability decreases when two components are in sequence.

Availability (Total)=Availability (Foo)∗Availability (Bar)

For example, if both Foo and Bar each had 99.9% availability, their total availability in
sequence would be 99.8%.

Parallel

Overall availability increases when two components are in parallel.

Availability (Total)=1−(1−Availability (Foo))∗(1−Availability (Bar))

For example, if both Foo and Bar each had 99.9% availability, their total availability in
parallel would be 99.9999%.

Vertical scaling:

Increasing the capacity of a single machine or server by adding more resources to it. This can
involve upgrading the hardware components such as CPU, memory, storage, or network
capabilities of the existing machine.

Example: Increased Workload: When the demand on an application or system grows, the
existing hardware may not be able to handle the increased load efficiently. Vertical scaling
can be done.

Data Growth: As the size of the data being processed or stored increases, the existing
storage capacity may become insufficient.

It does not save you from single point of failure.

Horizontal scaling:

increasing the capacity of a system by adding more machines or servers to distribute the
workload.

Increased User Base: When the number of users or clients accessing an application or service
grows, Horizontal scaling can be done which allows us to add more servers to distribute the
load and ensure that each user gets a responsive experience.

Big Data Processing: When dealing with large datasets or performing complex data
processing tasks, horizontal scaling can significantly improve performance
What is cache?
Cache is special very high-speed memory. It stores frequently used data and reduces
opera onal latency.

Distributed cache:
Group of cache servers which collec vely work to reduce latency.

In system client makes request, Service fulfill request using data in the database.

Database provide data to the service.

Cache minimizes opera onal latency

1. By reducing network calls.

2. Avoid computa on as some result is already stored in cache.

3. Reduce Database calls/loads.

How Cache minimizes opera onal latency

Cache store:

1. precalculated result.

2. pregenra ng expensive result.

3. Copies of frequently used data.

Why we cannot store everything in cache?

it will increase search space increase in search me.

hardware used in cache is expensive.

When do you load data into the cache? When do you evict data from the cache?

Loading or Evic ng data from the cache is called a Policy. So the cache performance depends on your
cache policy. there are two types of policy LRU ans LFU.
Problems with Caching

1. Making extra calls searching for the data which is not present in the cache memory this will
increase network latency.

2. Consistency suppose you have updated a value which is not updated in some cache and now if we
get the data from the same un-updated cache, it will cause us great problem.

3. Thrashing: repeatedly evic ng and reloading data at a very high rate, resul ng in poor
performance.

How to update data in distributed cache

there are two methods.

1. write through cache 2. write back cache.

Write back: The data is updated only in the cache and updated into the memory later in batch. Data
is updated in the memory only when the cache line is ready to be replaced (cache line replacement is
done using Belady’s Anomaly, Least Recently Used Algorithm, FIFO, LIFO, and others depending on
the applica on). there is chances of inconsistence data. this algo is used when data is frequently
used.

Write back is a storage method in which data is wri en into the cache every me a change occurs,
but is wri en into the corresponding loca on in main memory only at specified intervals or under
certain condi ons.

Problem:

There is chances of server failures which will lead to loss in updates.

Write-through Cache: Write-through cache is a caching mechanism in which data is wri en

simultaneously to both the cache and the main memory. When a write opera on occurs, the data is
first wri en to the cache, and then it is immediately wri en to the main memory as well. This
ensures that the data in the cache is always consistent with the data in the main memory.

Problems:

Memory Traffic: Frequent updates will increase Memory_Traffic/load_on_database

Higher latency for write opera on: Write-through caching can introduce higher latency for write
opera ons, as the CPU has to wait for the write opera on to be completed in both the cache and the
main memory before proceeding.

I general we use combina on of both algorithm write through(when less frequent writes) and write
back(when more frequent writes).

Where to place the Cache?

We can place cache close to the servers as well as close to the Database. If you place cache close to
the servers, How can you place it? You can place it in-memory itself (in-memory in the servers). Yes,
it will be faster if we use an in-memory cache with the server. But there will be some problems. Take
this example:

1. The first problem is the Cache failure. Assuming Applica on Server 1 failed. Now the Cache also
failed. We will lose that data in Applica on Server1.

2. The second thing is the consistency. Applica on server 1 data and Applica on server 2 data are
not the same. They are not in sync.

If we place cache close to the database using a Global cache the benefit is that all servers are hi ng
this global cache. If there is a miss it will query the database otherwise it will return data to the
servers. And we can maintain distributed caches here. And it will maintain the data consistency.

Sharding:

Dividing the database into small databases. Database sharding is the process of spli ng up a
database across mul ple machines to improve the scalability of an applica on.

In Sharding, one’s data is broken into two or more smaller chunks, called logical shards.

The logical shards are then distributed across separate database nodes, referred to as physical
shards.

Need of sharding:

Suppose a database of 100000 student record, Now when we need to find a student from this
Database, each me around 100, 000 transac ons has to be done to find the student, which is very
costly.

Benefits of Sharding:

• Smaller Databases are Easier to Manage.

• Scalable system.

• Smaller Databases are Faster.

Drawbacks of sharding:

• Adds complexity in the system: Properly implemen ng a sharded database architecture is a

complex task. If not done correctly, there is a significant risk that the sharding process can lead to
lost data or corrupted tables.

• Rebalancing data: In a sharded database architecture, some mes a shard outgrows other
shards and becomes unbalanced, which is also known as database hotspot. In this case any benefits
of sharding the database is cancelled out. The database would be likely need to be re-sharded to
allow for a more even data distribu on.

• No Na ve Support: Sharding is not na vely supported by every database engine. Because of

this, sharding o en requires a “roll your own”.
How applica on get the sharded data?

There are 2 ways

Applica on shard: If the applica on has some algorithm in it which reroutes to par cular shard.

Dynamic shard: in this we have separate modules which has loca on to every shard and tells where
the shad is.

Where do we apply sharding?

Sharding is o en applied to caching and database layer.

Asynchronous communica on in system design refers to the exchange of data between two or more
systems where there is no need for all par es to respond immediately. This type of communica on is
me-independent, meaning the receiver can respond to the message at their convenience.

What is a messaging queue?

A messaging queue is an intermediate component between the interac ng en es known as

producers and consumers. The producer produces messages and places them in the queue, while the
consumer retrieves the messages from the queue and processes them. There might be mul ple
producers and consumers interac ng with the queue at the same me.

Improved performance: Improved performance: A messaging queue enables asynchronous

communica on between the two interac ng en es, producers and consumers, and eliminates their
rela ve speed difference.

Be er reliability: The separa on of interac ng en es via a messaging queue makes the system
more fault tolerant. For example, a producer or consumer can fail independently without affec ng
the others and restart later. Moreover, replica ng the messaging queue on mul ple servers ensures
the system’s availability if one or more servers are down.

Granular scalability: Asynchronous communica on makes the system more scalable. For example,
many processes can communicate via a messaging queue. In addi on, when the number of requests
increases, we distribute the workload across several consumers.

Rate limi ng: Messaging queues also help absorb any load spikes and prevent services from
becoming overloaded, ac ng as a rudimentary form of rate limi ng when there is a need to avoid
dropping any incoming request.

Messaging queue use cases

1. Sending many emails: Emails are used for numerous purposes, such as sharing informa on,
account verifica on, rese ng passwords, marke ng campaigns, and more. All of these emails
wri en for different purposes don’t need immediate processing and, therefore, they don’t disturb
the system’s core func onality. A messaging queue can help coordinate a large number of emails
between different senders and receivers in such cases.
2. Recommender systems: Some pla orms use recommender systems to provide preferred
content or informa on to a user. The recommender system takes the user’s historical data, processes
it, and predicts relevant content or informa on. Since this is a me-consuming task, a messaging
queue can be incorporated between the recommender system and reques ng processes to increase
and quicken performance.

DNS stands for Domain Name System. It is a hierarchical and distributed naming system that
translates domain names to their corresponding IP address.

DNS works similar to a phonebook, where names are matched with phone numbers. In the same
way, DNS works by transla ng domain names such as google.com into IP addresses that computers
can understand, such as 216.58.192.14.

What is a load balancer?

A load balancer is a device that acts as a reverse proxy and is responsible for evenly distribu ng
network traffic across mul ple servers. Load balancers smooth out the concurrent user experience of
the applica on and improve reliability.

The requests received by a load balancer are distributed among mul ple servers using a configured
algorithm that could be based on:

• Round-robin

• Weighted round-robin

• Least response me

• Least connec ons

There are some other load balancing algorithms which I need to read and understand separately.

load balancers can ensure that transac on loads are distributed evenly across all servers, preven ng
any single server from becoming a bo leneck and ensuring smooth and efficient service to all users.

Load balancers ensure reliability and availability of servers around the clock by constantly monitoring
the load that each server is under and only sending requests to servers and applica ons that can
respond in a mely manner.

Hardware load balancer is quite expensive and used in big organiza on. While so ware load
balancer is less expensive as compare to hardware but are less powerful then hardware. Example:
AWS, Azure and GCP.
Database: structured set of data like tables, queues, forms, reports (NOT FORMAL DEFINATION)

Advantages:

• Manages large dataset

• consistency.

• Availability (Replica on)

• Scalability (sharding & Par oning)

Various types of database: Hierarchal, graph, network, Rela onal db(SQL) & Non-Rela onal
db(NOSQL) we will discuss only SQL vs NO-SQL.

SQL VS NOSQL

Rela onal Database:

1. Structure: RDBMSs structure data in a 'rela on' or table format of rows and columns. The
rows represent records, and the columns represent a ributes.

2. Schema: RDBMSs require a pre-defined schema set up before you can add data. This means
structure and data types must be specified beforehand.

3. Scalability: RDBMSs are typically scaled ver cally by adding more powerful hardware
resources.

4. ACID Transac ons: RDBMSs follow ACID proper es (Atomicity, Consistency, Isola on,
Durability) which ensures that transac ons are processed reliably.

5. SQL: RDBMS uses structured query language (SQL) for defining and manipula ng the data,
which is very powerful.

Non-Rela onal Database:

1. Structure: NoSQL databases can store data in mul ple ways - key-value pairs, wide-column
stores, graph databases, or document-based within the same database.

2. Schema: NoSQL databases are schema-less, meaning you can add any type of data you want
on the fly. No need to define what data types you have before you insert data.

3. Scalability: NoSQL databases are scaled horizontally, meaning one can add more servers to
the pool to handle the increased load.

4. CAP Theorem: NoSQL databases follow the CAP Theorem (Consistency, Availability, Par on
tolerance) which allows to choose two out of three.

5. Query Language: Most NoSQL systems do not offer a language equivalent to SQL in power,
and instead queries are typically made by a custom API to the database.

You can read more about RDBMS through notes.

ADD More about NOSQL. READ MEDIUM ARTICLE.

Microservices:

Cohesion: degree to which the elements within module are functionally related. It is the degree

Coupling: degree of interdependence between the modules.

In microservice architecture, mul ple loosely coupled services work together. Each service focuses
on a single purpose and has a high cohesion. of related behaviors and data.

This definition includes three microservice design principles:

 Single purpose — each service should focus on one single purpose and do it well.
 Loose coupling — services know little about each other. A change to one service should not
require changing the others. Communication between services should happen only through
public service interfaces.
 High cohesion — each service encapsulates all related behaviours and data together. If we
need to build a new feature, all the changes should be localized to just one single service.

Advantages

Here are some advantages of microservices architecture:

 Services can be deployed independently. (Loosely coupled)

 Highly agile for mul ple development teams.
 Improves fault tolerance and data isola on.
 Be er scalability as each service can be scaled independently.
 Eliminates any long-term commitment to a par cular technology stack.

Disadvantages

Microservices architecture brings its own set of challenges:

 Complexity of a distributed system.

 Tes ng is more difficult.
 Expensive to maintain (individual servers, databases, etc.).
 Inter-service communica on has its own challenges.
 Data integrity and consistency.
 Network conges on and latency.

Beware of distributed monolith/Challenges in implementing microservices

Distributed Monolith is a system that resembles the microservices architecture but is tightly
coupled within itself like a monolithic application. Adopting microservices architecture
comes with a lot of advantages. But while making one, there are good chances that we
might end up with a distributed monolith.

NOTE: Aim to implement microservices is not small code its to make services loosely coupled
API
API stands for "Applica on Programming Interface." An API acts as an intermediary that
enables different so ware systems to talk to each other and share data or func onality. It
provides a way for developers to access specific features or services of a so ware
applica on without needing to understand the internal workings of that applica on.
API gateway
An API gateway is a server that acts as a single point of entry for a set of microservices. It
receives client requests, forwards them to the appropriate microservice, and then returns the
server’s response to the client. The API gateway is responsible for tasks such as routing,
authentication, rate limiting, load balancing, caching, monitoring, and Transformation.

API gateways are used for a variety of purposes in microservice architectures, including the
following:

Routing: The API gateway receives requests from clients and routes them to the appropriate
microservice. This enables clients to access the various microservices through a single entry
point, simplifying the overall system design.

Authentication and Authorization: The API gateway can be used to authenticate client, This
helps to ensure that only authorized clients can access the microservices and helps to
prevent unauthorized access.

Rate limiting: You can rate limit client access to microservices with an API gateway. This can
help prevent denial of service attacks and other types of malicious behaviour.

Load balancing: The API gateway can distribute incoming requests among multiple instances
of a microservice, enabling the system to handle a larger number of requests and improving
its overall performance and scalability.

Caching: The API gateway can cache responses from the microservices, reducing the number
of requests that need to be forwarded to the microservices and improving the overall
performance of the system.

Monitoring: The API gateway can collect metrics and other data about requests and
responses, providing valuable insights into the performance and behaviour of the
microservices. This can help to identify and diagnose problems, and improve the overall
reliability and resilience of the system.

Request and Response Transformation: Request and response transformation in the

context of an API Gateway refers to the ability of the gateway to modify the data format or
structure of incoming client requests or outgoing responses before passing them on to the
backend microservices or returning them to the clients. Example: Let's say you have a
microservice that expects client requests to be in XML format, but your clients prefer to send
JSON requests. The API Gateway can handle this transformation by converting JSON requests
into XML before forwarding them to the microservice.

API Design

API design, which stands for Application Programming Interface design, refers to the process
of defining the rules and conventions that allow different software applications to
communicate and interact with each other.

Designing a high-quality API is crucial for ensuring its usability, flexibility, and maintainability.
Here are some best practices to consider when designing APIs:

Use Nouns for Resource Names: When defining endpoints, use nouns to represent
resources rather than verbs. For example, use /users instead of /getUsers.

Request and Response Formats: Use widely adopted data formats such as JSON or XML for
request and response payloads.

Authentication and Security: Implement secure authentication mechanisms like OAuth or

API keys to control access to the API and protect sensitive data.

Error Handling: Provide meaningful error messages and appropriate HTTP status codes for
different scenarios to help developers troubleshoot issues effectively.

Give feedback to help developers succeed

In general, there are three possible outcomes when using your API: -

1. The client application behaved erroneously (client error - 4xx response code)
2. The API behaved erroneously (server error - 5xx response code)
3. The client and API worked (success - 2xx response code)

Pagination and Filtering: Use pagination to handle large result sets and filtering options to
allow clients to request specific data.

Caching: Support caching of responses where applicable to reduce server load and improve
API performance.

Documentation: Create comprehensive and user-friendly documentation for the API,

including clear usage examples and explanations.
What is an event?
An event is a data point that represents state changes in a system. It doesn't specify what
should happen and how the change should modify the system, it only no fies the system of
a par cular state change. When a user makes an ac on, they trigger an event.
What is event driven architecture?
An event-driven architecture uses events to trigger and communicate between decoupled
services and is common in modern applica ons built with microservices. An event is a
change in state, or an update, like an item being placed in a shopping cart on an e-commerce
website. Events can either carry the state (the item purchased, its price, and a delivery
address) or events can be iden fiers (a no fica on that an order was shipped).

Polling: simply means checking for new data over a fixed interval of me by making API calls
at regular intervals to the server.

Components
Event-driven architectures have three key components:
• Event producers: Publishes an event to the router.
• Event routers: Filters and pushes the events to consumers.
• Event consumers: Uses events to reflect changes in the system.
Producer services and consumer services are decoupled, which allows them to be scaled,
updated, and deployed independently.
Benefits of an event-driven architecture
Scale and fail independently
By decoupling your services, they are only aware of the event router, not each other. This
means that your services are interoperable, but if one service has a failure, the rest will keep
running. The event router acts as an elas c buffer that will accommodate surges in
workloads.
Develop with agility
You no longer need to write custom code to poll, filter, and route events; the event router
will automa cally filter and push events to consumers. The router also removes the need for
heavy coordina on between producer and consumer services, speeding up your
development process.
Audit with ease
An event router acts as a centralized loca on to audit your applica on and define policies.
These policies can restrict who can publish and subscribe to a router and control which users
and resources have permission to access your data. You can also encrypt your events both in
transit and at rest.
Cut costs
Event-driven architectures are push-based, so everything happens on-demand as the event
presents itself in the router. This way, you’re not paying for con nuous polling to check for
an event. This means less network bandwidth consump on, less CPU u liza on, less idle
fleet capacity, and less SSL/TLS handshakes.

Example architecture:
h ps://d1.awssta c.com/product-marke ng/EventBridge/1-SEO-Diagram_Event-Driven-
Architecture_Diagram.b3 c18f8cd65e3af3ccb4845dce735b0b9e2c54.png

Virtual machine vs container

A virtual machine (VM) is a so ware simula on of a computer system. It enables mul ple
opera ng systems to run simultaneously on a single physical computer, isola ng each
environment from each other. Virtual machines use physical system resources and provide a
full-fledged virtual environment where a guest system operates as if it were running on
physical hardware.
A container, on the other hand, is a standalone, executable so ware package that includes
everything required to run a piece of so ware, including the code, run me, system tools,
system libraries, and se ngs. Containers are lighter than VMs because they share the host
system’s OS kernel instead of requiring their own OS, which allows them to boot up quickly
and consume less memory.
While both technologies are used to create isolated environments for running applica ons,
containers are more lightweight and provide process-level isola on, while virtual machines
provide full opera ng system-level isola on.
Difference
Performance: Containers are lightweight and require less resources, as they run directly on
the host machine's kernel. This allows you to get more applica ons onto a single server
compared to a VM.
• Size: A container may only be tens of MBs in size as it takes only the applica on and
necessary binaries and libraries. In contrast, a VM could be several GBs in size as it includes a
full-fledged opera ng system and applica ons.
• Start Time: Containers can start almost instantly, while VMs usually take a longer me to
boot up, since they need to load the en re opera ng system.
• Opera ng System: Containers share the same OS kernel of the host machine, with each
one running as an isolated process on the host OS. Whereas each VM runs its own opera ng
system, independently from the host and other VMs.
• Isola on: VMs provide isola on at the hardware level, each one running on its own
separate machine, whereas containers provide isola on at the OS level, opera ng as
separate processes on the host's OS.
• Use Case: Containers are best for deploying mul ple instances of an applica on across
different environments, making them great for scalable cloud-na ve applica ons. VMs are
more suited for running applica ons or services that require all the resources and
func onality of a separate opera ng system.
• Security: VMs are generally considered more secure as they are isolated at the hardware
level and do not share an OS. In contrast, Containers have a larger surface for a acks since
they share the same OS and a bug in the kernel could poten ally affect all containers on the
host.
Popular container providers: Docker & Linux Containers (LXC).
Popular virtual machine providers: VirtualBox & VMware

Load balancer vs reverse proxy

While both load balancers and reverse proxies can distribute traffic among mul ple servers,
they have different primary func ons and use cases:
Reverse Proxy: A reverse proxy takes client requests and sends them to an appropriate
backend server to handle them. Once the server is done handling the request, the reverse
proxy sends the response back to the client. Reverse proxies can also provide func onality
such as SSL encryp on, cache sta c content, and compression. They work at the applica on
layer (Layer 7) of the OSI model.
Load Balancer: A load balancer's primary role is to distribute incoming network traffic evenly
among mul ple backend servers to ensure no single server becomes overwhelmed, hence
improving the overall system performance, availability, and resilience. If one server goes
down, the load balancer redirects traffic to the remaining online servers. Load balancers
operate at both the transport layer (Layer 4 - TCP/UDP) and at the applica on layer (Layer 7 -
HTTP/HTTPS).
In many cases, a load balancer also serves as a reverse proxy, but not all reverse proxies can
func on as load balancers due to their specific design and capabili es.