Understanding System Design

My First Step Into Intermediate Cloud Engineering: Understanding System Design
I have been studying system design for cloud engineering so that I can build real-world, intermediate-level projects.
While learning cloud engineering, I realized that system design is one of its most important foundations.
In my opinion, cloud engineering is largely about understanding how different components work together to build reliable, scalable, and maintainable infrastructure.
If we do not understand system design, it becomes difficult to create infrastructure that can handle many users, large amounts of traffic, and unexpected failures.
The Architecture I Studied
I watched a YouTube video about a cloud-based system architecture.
After studying the architecture, I tried to understand how a request moves through different components in a modern application.
Based on my understanding, I created my own diagram of the architecture.
I will include both the YouTube video link and my architecture diagram in this blog.
YouTube Video
This is the YouTube video I studied to understand the architecture:
https://youtu.be/lFeYU31TnQ8?si=8hL6UsgvNykh_8QE
I created this architecture diagram in Excalidraw:
How the Request Works
The request first goes through DNS.
DNS resolves the domain name and directs the request toward the CDN or API Gateway.
If the requested content is already available in the CDN cache, the CDN returns it directly to the user.
If the content is not available in the CDN, the request continues to the API Gateway.
The API Gateway checks the request and routes it to the appropriate backend service.
The request is then sent to the relevant load balancer.
The load balancer distributes the request among multiple servers.
These servers can be EC2 instances, containers, or serverless functions.
Cache and Database
When the request reaches the backend service, the service first checks the application cache.
If the requested data is available in the cache, the service returns it quickly.
If the data is not available in the cache, the service retrieves it from the database.
After retrieving the data, the service stores it in the cache.
The service then returns the data to the user.
This approach reduces repeated database queries and improves application performance.
Multiple Services
In a large enterprise system, multiple services can run on multiple servers.
Each service can be responsible for a specific function, such as:
User management.
Orders.
Payments.
Authentication.
Email notifications.
This type of architecture allows services to be developed, deployed, and scaled independently.
Monitoring and Auto-Scaling
The servers and services should be monitored using metrics such as:
CPU usage.
Memory usage.
Request volume.
Response time.
Error rate.
Message-queue length.
Auto-scaling can add more servers when demand increases.
It can also remove unnecessary servers when demand decreases.
This helps the system handle traffic efficiently while controlling infrastructure costs.
Event-Driven Email Service
For email communication, an event-driven architecture can be used.
When an important action occurs, such as a new order or account registration, the service publishes an event.
The event is placed on a message queue or event bus.
An email notification worker consumes the event and sends the email asynchronously.
This prevents the main request from waiting for the email to be sent.
If email delivery fails, the system can retry the message.
After repeated failures, the message can be moved to a dead-letter queue for investigation.
Final Thoughts
This architecture helped me understand how DNS, CDNs, API gateways, load balancers, servers, caches, databases, queues, and notification services work together.
I am still learning system design, but creating this diagram helped me connect the theoretical concepts with practical cloud engineering.
My goal is to continue studying these concepts and use them to build intermediate-level cloud projects.
Understanding system design is an important step toward building scalable and reliable cloud infrastructure.





