Hello Reader,

Not all System Designs are created equal! To make matters complicated, there are so many designs out there.

As a former Principal Solutions Architect at AWS and Distinguished Cloud Architect at Verizon, I have taken over 300+ interviews, and I have seen three patterns coming over and over in interviews.

In this newsletter edition, we will go through 3 System Design patterns that appear the MOST in cloud interviews and actual projects.

If you nail these 3, you will be ahead of the majority of candidates walking into that room.

1/ Synchronous Microservice

This is the most popular design.

In a synchronous microservice, the caller waits for the response in the same invocation. You use microservices every day without knowing.

Checking bank balances.
Reserving dinner at a restaurant.
Posting a movie review.
Buying something from Amazon.

All done via microservice.

There are many ways to implement a microservice, but two variations are most popular. I am showing one example with API Gateway. The other way is with Load Balancer which is also very popular.

Let's inspect the below pattern:

• API Gateway hosts the API. You can use either REST or HTTP API. But REST is more popular due to availability of more features
  ​
• One thing you may not know - API Gateway timeout WAS 29 seconds, but last year AWS removed this limitation. In last couple interviews, some candidates gave me this answer incorrectly. ​
  ​
• You define API methods like GET, POST, and integrate an AWS service for each method
  ​
• In this case, for the POST method, API Gateway is sending the transaction to Lambda, Lambda executing database operations in DynamoDB and sending the response back in the same invocation
  ​
• You can integrate Route 53 to tie your API to a custom domain
  ​
• This is the fundamental design, and then you integrate security, monitoring as required by your application

2/ Event-Driven Architecture

An event-driven architecture decouples the producer and consumer. This has become very popular in the last couple of years.

In this example, the producer (human) invokes an API and sends information via a JSON payload. API Gateway puts it into an event store (SQS), and the consumer (Lambda) picks it up and processes it.

Note that, the API gateway and Lambda can scale (and managed/deployed) independently.

Benefits of an event-driven architecture (remember these for interviews)

• 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 elastic buffer that will accommodate surges in workloads. The producer and the consumer can scale independently.
• Develop with agility - You no longer need to write custom code to poll, filter, and route events (vary based on services).
  ​
  For example, if you use SQS with Lambda, AWS handles the polling, and retry mechanism. You can implement nuanced filtering logic in EventBridge, and can invoke different target based on event filtering, removing the need of managing and maintaining these rules in the code itself.
  ​
• Cost effective - Since you don't have to scale every component at the same time, you don't need to allocate higher capacity especially to the consumer.
  ​
  Imagine if you had RDS database, that needed to scale at the same high rate producer is sending traffic, you need to have a large RDS instance costing you lot of money. Whereas with EDA, you can keep RDS size smaller because consumer can scale much lower since SQS will hold the messages.

3/ Kubernetes Ingress

If you mention Kubernetes (k8s) in your LinkedIn/Resume, you MUST know this one.

This is the most common pattern used in real-world Kubernetes applications. It's the microservice implementation in Kubernetes.

• A Load Balancer works as k8s ingress accepting traffic. You can integrate Route 53 to to assign a custom domain
  ​
• You can do path-based routing in this ingress
  ​
• Important - In a load balancer service, you can NOT do path-based routing. This is a major difference between ingress and load balancer service. Remember this for the interview
  ​
• Based on URL path, traffic is sent to specific deployments
  ​
• Traffic can be sent to a nodeport service and then to pods, or you can use target type IP and pod IPs get registered with load balancer directly, and traffic goes directly from this ingress to the pod, saving an extra hop (load balancer to nodeport, and then nodeport to the pod)

Quick question for you: Which of these 3 patterns are you least confident about right now? Hit reply and let me know - I read every response.

Keep learning and keep rocking 🚀,

Raj

P.S - If you want to get an AWS Solutions Architect job without coding or learning every AWS service, waitlist for 8th cohort for SA bootcamp:

It's a one stop shop where we cover tech, behavioral, executive communication, hands-on, LinkedIn/resume improvement, mock interview and more. ​

I will also reveal my stealth startup product that I have been working on!

Next cohort launching May 16th. Spots are limited, so don't miss it!