Skip to main content

Command Palette

Search for a command to run...

Understanding System Design

Updated
4 min readView as Markdown
Understanding System Design
S
Hi! I’m Muhammad Subhan Arif, a student based in Faisalabad with a passion for cloud infrastructure and platform engineering. I started this blog to document my path toward becoming a Cloud Engineer.

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:

View the architecture diagram

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.

System Design

Part 1 of 1

Learning System Design for Cloud Engineering