Hey fellow dev, long time no see! Hope you’re enjoying the spring weather. Today, we’re going to talk about microservices. This will be a series of articles where I explain how we arrived at this architectural pattern, its benefits, and then walk through building two microservices and setting up communication between them.
This first article will focus on theory. I hope you’re ready let’s get started!
Times Before: Chunky Monoliths
Before microservice architecture became popular, developers primarily worked with large monolithic applications. In this approach, all functionality lives in a single repository and is deployed as one unit. Any change to any part of the application requires redeploying the entire system.
Another issue is that if one part goes down, the entire application can be affected, so a single faulty deployment can bring down the whole system. Refactoring the code can also become a challenge of its own. Additionally, development teams are typically constrained to a single language, which can limit the pool of developers who prefer working with other technologies.
For small applications, this approach works well. However, as functionality grows and more teams begin working on the same codebase, challenges start to emerge.
That said, I’m not going to claim that a monolith is inherently bad, it can be beneficial in certain scenarios. But one of its biggest drawbacks is scalability, and addressing that limitation is what ultimately led to the rise of microservices.
Microservices: New Approach To Scalability Issues
Microservices are not a new concept, they started emerging in the early 2000s but gained significant popularity around 2013.
The main idea behind this architectural pattern is to separate concerns and break an application down based on specific functionalities. For example, consider an online shop: it has products, users, a shopping cart, and more. A microservices approach would split this application into distinct chunks of functionality, each potentially with its own database. The goal is to make these services independent from one another and easier to scale.
In this case, you might have a User Service as one microservice and a Product Service as another, each responsible for its own domain.
So, the benefits of using microservice architecture include:
👉 Easier scaling
👉 Easier maintenance of the codebase
👉 The ability to choose different technology stacks, such as programming languages, database types, and more, for each service.
👉 Easier for different development teams to work independently on separate parts of the system
When to select Microservice vs Monolith
So, after learning a little bit about monoliths and microservices, you probably want to know when to use the right approach. And no, you should not apply microservices everywhere.
These are just architectural approaches, and the decision depends on the type of application you’re building:
👉 How large it is going to be
👉 Whether its scope is likely to expand
👉 Whether new features will be added frequently
👉 Whether it involves multiple databases or complex domains.
For large and complex applications with multiple functionalities that you expect to grow significantly over time, microservice architecture might be the right choice. For something small and simple that is not expected to grow much in the future, a monolith will work just fine.
Sometimes it’s perfectly fine to start with a monolith and then refactor to something else if the need arises. Microservices require more resources and more initial setup compared to a traditional monolithic approach. On top of that, you also need to ensure that your services can communicate with each other effectively. Let’s find out how this can be done.
How Microservices talking to each other
In a typical monolith, you have your controllers, business logic, and database interactions all within a single project. It can grow quite large, but the entire application is still one unit with a single entry point. For example, when you send an API request to update a shopping cart, that request flows through the business logic, and all necessary parts of the application are updated, usually within a single request.
With microservices, things work differently. When you update something, you often need to notify other services about that change. This can be done either through direct API calls or through messaging, with messaging being the more popular approach.
This messaging is part of event-driven architecture, which often goes hand in hand with microservices and defines how services communicate.
The basic idea is this:
Something is updated in Service A such as a user’s first name. The request is processed, and the database is updated. After that, Service A publishes a message (an event). Other services (B,C and etc) that need this information are listening for such updates. When they receive the message, each service processes it independently (each gets its own copy) and typically updates its own database or performs a specific action based on that event.
Let’s talk more about it.
Event Driven Architecture:
So, in this type of architecture, we have a consumer (a service that consumes messages and processes them) and a producer (a service that sends messages after an update). The idea is simple.
We also have topics, a core concept in event-driven architecture. You can think of a topic as a channel where messages are published.
A topic is where messages of a certain type are sent. For example, if you subscribe to a sports news channel on WhatsApp or another messaging app, that channel publishes only sports-related content. You and many others can read or listen to those updates. The concept is very similar.
Another important component is the broker. This is the system that sits between producers and consumers. In our example, WhatsApp or Telegram itself would act as the broker, handling the delivery of messages.
There are multiple technologies that support event-driven architecture. For example, Azure Service Bus acts as a broker where you can create topics, and within those topics, define subscriptions that listen for messages and trigger updates in your services.
Other popular options include Apache Kafka and RabbitMQ, among others, so there are plenty of choices depending on your needs.
In the next article, we’re going to build an application using a microservices architecture and make the services communicate using RabbitMQ.
Stay tuned, and Happy coding!🚀
Comments