1 Simple Technique to Scale Microservices Architecture 🚀
#66: How Great Software Engineers Build Microservices (2 Minutes)
Get the powerful template to approach system design for FREE on newsletter sign-up:
You will find references at the bottom of this page if you want to go deeper.
Share this post & I'll send you some rewards for the referrals.
Once upon a time, there was a tech startup.
They tracked food deliveries in real-time.
Yet they had only a few customers; so, a simple monolith architecture was enough.
Until one day, an influencer with a massive following shared their app, and traffic skyrocketed.
So they moved to microservices architecture for scale.
Although it temporarily solved their scalability issues, there were newer problems.
Here are some of them:
Implementing new features became difficult because of the dependencies between microservices.
The operational complexity increased due to different programming languages across microservices.
Onward.
“Building a Scalable Authorization System: A Step-By-Step Blueprint” Ebook by Cerbos - Sponsor
Authorization can make or break your application’s security and scalability. From managing dynamic permissions to implementing fine-grained access controls, the challenges grow as your requirements and users scale.
This eBook will guide you through the 6 key requirements all authorization layers should include to avoid technical debt:
Architectural and design considerations for building a scalable and secure authorization layer.
20+ technologies, approaches, and standards to consider for your permission management systems.
Practical insights, based on 500+ interviews with engineers, architects, and IAM professionals.
Learn how to create an authorization solution that evolves with your business needs, while avoiding technical debt.
How to Scale Microservices
They wanted to reduce the maintenance effort and scale microservices quickly.
So they relied on automation.
Here’s how:
1. Server Management
A microservice must be scaled to handle changing traffic.
Yet scaling manually is slow and causes errors.
So they use infrastructure as code to keep things simple; it’s used to deploy new instances based on demand. Infrastructure as code means managing and provisioning infrastructure using code.
Ready for the next technique?
2. API Definition
It’s difficult to understand and maintain APIs without a proper naming convention.
Yet maintaining consistent naming for APIs across microservices is hard.
So they generate APIs using code and store API definitions as JSON in a separate Git repository.
Here are the benefits of code-generated APIs:
API paths can be validated using linters.
API naming conventions and request-response structures are standardized.
API version changes can be tracked through tagging.
It ensures API operations are defined.
User-friendly API paths can be set up as default.
Also it standardizes APIs built using different programming languages. Put simply, code generation makes it look like a single person wrote APIs across the system.
Besides code generation ensures health checks are included in each microservice.
Here’s how it works:
A health check URL is included in the API specification of the microservice.
It returns HTTP status code 200 if the microservice is healthy.
Otherwise, it returns HTTP status code 422.
An unhealthy service is removed from production to avoid service interruptions.
3. Database Architecture
A change to database schema shouldn’t break microservices depending on it.
Yet sharing a single database across microservices introduces tight coupling and failure risk.
So they set up separate databases for each microservice.
But maintaining many databases is a huge effort; so, they create databases and tables using code.
Here are its main benefits:
Consistent database names.
Normalized data access.
Ensure proper database indexes exist from the start.
Easy to maintain and operate the database.
Besides a microservice shouldn't talk to a database owned by another microservice. Instead, communication happens only via the microservice’s API owning the database. Otherwise, the data changes aren't safe as they bypass business logic.
The bottom line: use code generation and automation to scale microservices quickly. It reduces maintenance efforts and helps with version control.
👋 PS - Do you want to level up at work and better understand technical discussions?
My mission is to help you go from 0 to 1 in system design by spending less than 37 minutes a month.
I launched the newsletter deep dives last month.
Yet future deep dives, starting this month, are available only to paid subscribers.
And subscription fees will be higher than the current fees.
So pledge now to get access at a very low price.
“This newsletter is an amazing resource for learning system design.” Alex
Subscribe to get simplified case studies delivered straight to your inbox:
Want to advertise in this newsletter? 📰
If your company wants to reach a tech audience, you may want to advertise with me.
TL;DR 🕰️
Thank you for supporting this newsletter. Consider sharing this post with your friends and get rewards. Y’all are the best.
A bad microservice handles multiple domains.
A good microservice handles only one of the business’s domains.
Great article, Neo!
Step #3 is where many teams drop the ball, failing to understand the complexity and scalability limitations that shared database produces.
Simply put, Neo!