đś Spicy take: âStart with a microservice architecture. Never start with a monolith. Thereâs a tendency to want to start with a monolithic project because it makes for a great proof of concept. However, scaling it is nearly impossible, and refactoring your monolith to a microservice can take years or at least months.â - Yaniv Ben Hemo
When I asked Yaniv Ben Hemo how people should decide whether to build a monolithic or microservice architecture project, he gave me the above advice. Yanivâs advice stemmed from his prior experiences building a monolith and struggling to scale it. Also, please note that Yaniv is often building data intensive apps that he feels scale better in a microservice architecture. Eventually, these experiences inspired him to build Memphis, a message broker that enables developers to build microservices easily. You can read more about his passion for building microservices and how to get started here.
Microservices vs. Monoliths
Before I go any further, letâs start by differentiating a monolithic architecture versus a microservices architecture. In a monolithic project, all functions and processes run in a single service. However, as with any project, open source or proprietary, you add more features to the project. This can create bloat and unnecessary complexity. In a microservice architecture, you have multiple, independent components that communicate with each other to run an application. Each microservice is responsible for a single function.
Is Twitter built on a Microservice architecture? Probably!
Hereâs an illustration. Although I donât know the intricacies of Twitterâs design system, I do know that it has multiple features and services. The multi-feature offerings are one of the reasons I enjoy using Twitter. I normally use Twitter to read my timeline, participate in Spaces, interact with tweets, update my profile, subscribe to newsletters, search for past tweets, and view analytics. This doesnât even scratch the surface of all the features within Twitter. I imagine if Twitter is a monolith, the Twitter engineers are probably stressed! If I were to create a Twitter clone or my own version of Twitter(even to handle the few features I listed), I would build a microservice for each of the following components:
- Analytics Service - This service reports the analytics for each Twitter account
- Search Service - This service allows you to search for tweets and keywords on Twitter.
- Profile Service - This service serves as a profile for each account showing their profile picture, bio, and recent tweet interactions.
- Spaces Service - This service allows you to host, listen, and participate in Twitter Spaces.
- Home Timeline Service - This service allows you to read your timeline.
- Newsletter Service - This service allows you to create and subscribe to newsletters via Revue.
- Tweet Interaction Service - This service allows you to like, retweet, and post tweets.
An image of what Twitter analytics looks like
Each microservice can live in its own repository. This structure allows me to add more features without disrupting the existing features. Also, if a microservice is down, it shouldnât affect the entire application. If Spaces didnât work due to a bug, users could still create tweets, read tweets, subscribe to newsletters, search for tweets, and update their profiles.
Microservices use message brokers to communicate
Although microservices work independently, they share data. Letâs use the example of a Twitter Clone microservice. My Tweet Interaction service needs to communicate with the Profile service to know what tweets I liked, retweeted, or responded to, so that it can reflect my likes, retweets, and replies on my profile page. To communicate, microservices use message brokers.
Iâve worked with microservices in the past, but I had many questions about the terminology. The concept of message brokers, message queues, producers, and consumers seemed foreign to me, so Iâll use the rest of this blog post to define these words in laymanâs terms.
What is a message queue?
If you took formal Computer Science school, you mightâve heard of the term queue. If not, Iâm happy to explain it to you! A queue is similar to a line in real life (like one at a cash register or a line of cars in traffic). Whoever stood in the line first, gets to leave first! This data structure follows a FIFO order, which stands for first in, first out! The first item added to the queue is the first item to leave the queue. Similarly, a message queue contains messages with data about events that follow the FIFO order.
What is a message broker?
When an event occurs, a message with data joins the message queue or âline,â then a message broker, appropriately nicknamed a service bus translates and transports the message to the appropriate service. Message brokers are responsible for managing the transportation and translation of all messages from one microservice to another.
What is a producer?
As the name suggests, producers create and send the data from one microservice to another.
What is a consumer?
Similarly, consumers receive data from a microservice and perform operations based on the data received.
An image of a producer and consumer in Memphis
What is a station?
A station is a term unique to Memphisâ platform. If youâre familiar with Kafka or RabbitMQ, a station is the equivalent of a topic or queue. Stations provide a powerful yet easy-to-use messaging queue for apps.
An image of a station in Memphis' platform
What is a factory?
This is a term thatâs unique to the Memphis platform. A factory presents the application/use case that the user requires to build, and, within it, all the stations (queues) that establish the use case.
If youâre interested in better understanding microservices, data, or message brokers, follow Memphis on DEV for more content!
Check out the Memphis repository and give them a star! đ
Top comments (2)
By message queue, people (atleast me đ ) usually mean a "message queuing service" (which includes message broker).
But I liked the clear distinction between the two you tried to establish via this blog.
I shall use the term "message broker" or "message queuing service" to make it more explicit from now onwards. đ
Thanks! I never heard anyone refer to it as a message queuing service. I learned something new because of you.