System design for Global level application - For beginners
Basic System design for Global level application
1. Client and Server Roles in System Design
-
Client: The client is typically a user's device (mobile app, browser, etc.) that sends a request to get some data or perform some action.
-
Server: This is a machine (computer) that runs 24/7 and listens for client requests, processes them, and returns a response.
-
Think of it like ordering food online (client) and the restaurant kitchen preparing and delivering it (server).
2. Public IP Address
-
For a server to be accessed over the internet, it needs a public IP address.
-
This makes it globally accessible.
-
Example: Just like your phone has a unique number, servers have IPs.
3. Domain Names Instead of IP
-
IP addresses are hard to remember (like
142.250.78.206
), so we use domain names likeamazon.com
. -
These names are easier for humans to remember and use.
4. What is a DNS Server?
-
DNS (Domain Name System) is like a phonebook of the internet.
-
It converts domain names into IP addresses.
-
When you type
google.com
, DNS helps your computer find the right server to talk to.
5. DNS Resolution
-
This process of converting a domain name into an IP is called DNS resolution.
-
Your browser sends a query to a DNS server asking, "What is the IP of amazon.com?"
-
DNS replies with the correct IP.
6. Server Scaling (Why It's Needed)
-
If many users use your app at the same time, your server may slow down or crash.
-
Scaling means preparing your server to handle more users or traffic.
7. Vertical Scaling
-
Add more power to a single server: increase CPU, RAM, etc.
-
Called "scaling up".
-
Good for small to medium traffic.
-
But… it has limits.
8. Problems with Vertical Scaling
-
Server might need a restart after upgrades → downtime (bad for apps like Amazon).
-
Also, one big server = single point of failure.
9. Horizontal Scaling
-
Instead of one powerful server, you use multiple small servers.
-
Called "scaling out".
-
Spread traffic among them using a Load Balancer.
10. What is a Load Balancer?
-
Distributes traffic to multiple servers.
-
Uses strategies like:
-
Round Robin: turn by turn
-
Least Connections: least busy server
-
-
Ensures no single server is overwhelmed.
11. Health Checks by Load Balancer
-
Load balancers continuously check server health.
-
If a server crashes, it won’t send traffic there.
-
New servers must register with the load balancer.
12. Microservices Architecture
-
Break a large app into small services:
-
Auth Service
,Order Service
,Payment Service
, etc.
-
-
Each service has its own server(s) and can be scaled independently.
13. API Gateway
-
A single entry point for all API requests.
-
Routes incoming requests to the right microservice.
-
Acts as a reverse proxy.
-
Helps with authentication, rate limiting, and logging.
14. Load Balancer Behind API Gateway
-
API Gateway forwards requests to the load balancer of the appropriate service.
-
Load balancer then sends the request to a healthy server (like an EC2 instance).
15. Authenticator with API Gateway
-
API Gateway can have an authentication layer.
-
Ensures only valid users can access the backend services.
16. Batch Processing
-
Used for background tasks like:
-
Sending emails
-
Generating reports
-
-
A worker (background process) reads from the database and performs these tasks.
17. Async Communication with Queues
-
Instead of calling services directly, one service can push a message to a queue (like SQS).
-
Worker pulls messages from queue and processes them.
-
Helps in decoupling services and retrying failed tasks.
18. Horizontal Scaling of Workers
-
You can run multiple workers in parallel.
-
Each can process a message simultaneously = faster processing.
19. Rate Limiting in Workers
-
You can set limits, like "send only 10 emails per second", to:
-
Avoid spam
-
Respect 3rd-party API limits
-
20. Async Communication Mechanisms
-
SQS (Simple Queue Service) can act as:
-
Push (messages sent to queue)
-
Pull (worker pulls when ready)
-
-
Good for decoupling microservices.
21. Pub/Sub Model
-
One event → multiple services react.
-
Example: On payment success:
-
Send email
-
Send SMS
-
Update dashboard
-
-
Each service subscribes to the same event.
22. Pub/Sub vs SQS
-
Pub/Sub → message goes to all subscribers.
-
SQS → message goes to one consumer.
23. Event-Driven Architecture
-
Microservices respond to events instead of direct calls.
-
Problem: Sometimes services may not acknowledge (ack) receipt of event.
24. Fan-Out Architecture
-
One event → message sent to multiple queues:
-
WhatsApp Queue
-
Email Queue
-
SMS Queue
-
-
Each queue has its own worker.
25. Fan-Out Use Case
-
Example: A video is uploaded.
-
Transcribe audio
-
Generate thumbnail
-
Process video
-
-
One event triggers multiple actions in parallel.
26. Rate Limiting
-
Helps prevent abuse or overload.
-
Example: Max 100 API calls per minute per user.
-
Protects backend from traffic spikes.
27. Database Scaling
-
One database can’t handle huge traffic alone.
-
Use read replicas to handle more traffic:
-
Primary handles writes
-
Replicas handle reads
-
28. Read Replicas
-
Help offload the main database.
-
But... have slight delay (eventual consistency).
29. Caching Layer
-
Frequently requested data is stored in cache (e.g., Redis).
-
Avoids repeated database hits.
-
Makes system faster and more efficient.
30. Content Delivery Network (CDN)
-
CDN stores static content (images, videos, CSS, JS) closer to users.
-
Reduces latency.
-
Example: CloudFront
-
If cache miss → fetches from server, stores in cache.
-
31. CloudFront and Anycast
-
Uses Anycast IP → same IP can reach nearest server.
-
User gets content from the closest location = faster delivery.
-
Saves bandwidth and improves user experience.
32. CDN Summary
-
Acts like a global cache layer.
-
Improves performance, reduces server load, and saves bandwidth.
Comments
Post a Comment