Microservices Vs. Event Driven Plus SA Interview Mistakes


Hello Reader,

The two most prominent architecture patterns are microservices and Event-Driven Architecture (EDA). Let’s examine their differences and implementations, with the architecture diagram below:

Request Response Flow

Traditional microservice is synchronous i.e. the request and response happens on the same invocation. For example, if you are inserting data into the backend database using a microservice as shown in the left diagram, the invocation from the user will stay active till the Lambda inserts the info into the database, replies success back to the API Gateway, and API Gateway sends the response back to the user.

Whereas with Event Driven, User gets a confirmation that the message is inserted into an event storage/processing service (SQS in this case) using the API Gateway. But he doesn’t get the response from the Lambda, which is inserting the message into the database, on the same invocation. Instead, the backend Lambda needs to send the response out after the message has been inserted into the database if the user needs to be notified. In this case the Lambda is invoking a websocket API, to notify the user. Alternatively, the user can query the status of the message independently using a separate microservice.

Scaling (Important!)

In a microservice, all the components (API Gateway, Lambda, Dynamo) need to scale up and down at the same rate. When traffic increases, all these three components will scale up together. However, if concurrent traffic exceeds a threshold beyond a service, let’s say Dynamo or Lambda max concurrency limit, transaction will fail.

With EDA, the producer and consumer are decoupled. API Gateway, and Lambda/Database can scale independently. When traffic increases, API Gateway can scale up and insert messages into the SQS. However the backend Lambda and Dynamo are protected from this burst. Lambda can consume messages at a rate not to overwhelm the database. This also leads to EDA being more cost effective.

Retry Mechanism

If a microservice transaction fails, the user needs to send the request again. There is no default retry mechanism. With EDA, once the message is in SQS, even if Lambda fails, SQS will automatically retry to reprocess the messages.

Conclusion

So which one is better? Well, as always, the answer is “it depends”! EDA can handle higher scale, and is generally more cost effective than synchronous microservice. However, in some cases you need a traditional synchronous microservice. In most applications, microservice and EDA can work together. There are parts of applications that can be broken down to be EDA. As we architects like to say, it’s NOT all or nothing, instead it’s the right tool for the right job.

AWS Solutions Architect Interview Mistakes

As a veteran interviewer, I see these mistakes costing candidates the offer. I explained these common (yet secret!) errors with actual questions and answers in this video:

video preview

If you have found this newsletter helpful, and want to support me 🙏:

Checkout my bestselling courses on AWS, System Design, Kubernetes, DevOps, and more: Max discounted links

AWS SA Bootcamp with Live Classes, Mock Interviews, Hands-On, Resume Improvement and more: https://www.sabootcamp.com/

Keep learning and keep rocking 🚀,

Raj

Fast Track To Cloud

Free Cloud Interview Guide to crush your next interview. Plus, real-world answers for cloud interviews, and system design from a top Solutions Architect at AWS.

Read more from Fast Track To Cloud

Hello Reader, I have been a Cloud Solutions Architect for 10 years - 4 years at Verizon, 6.5 years at AWS. I was an Application Cloud Architect at Verizon, and then I joined AWS, where I had two different SA roles - first a General SA (Enterprise Architect) and then a Specialist SA. In this post, I will review my responsibilities as an SA in all these companies, including the hardest parts of the job (in my humble opinion). Let's get started: Solutions Architect at Verizon I became a SA at...

Hello Reader, In today's newsletter, I am going to share three tips that helped me and many of my students switch careers to the cloud and get high-paying jobs. I will also share an update about the upcoming Sep cohort of the AWS SA Bootcamp. Tip 1: Leverage your IT experience Your existing IT experience is NOT throwaway. Don't think you can't reuse components of your existing knowledge in your cloud journey. For example, my mentee and SA Bootcamper Rukmani, came from software engineering...

Hello Reader, In today’s post, let’s look at another correct but average answer and a great answer that gets you hired for common cloud interview questions. And this ties to a larger thread - most candidates fail their Solutions Architect interviews - not because they’re underqualified… But because they don’t know how to communicate like a Solutions Architect. How to stand out as a must-hire? Let's start with a common question, and we will go from there! Question - What's the difference...