User shouldn’t be bothered with backend multilevel processes — what important for them is their action should be reflected in the timely manner.
With that in mind, we decouple our applications using RabbitMQ for the following jobs :
- Push Notification : likes, comment, mention, tag, follow and so on.
- SMS : phone number verification during on-boarding stage.
- Email sender : email registration & update.
One of the advantages by architecting this approach is we can scale horizontally. A message queue makes it easy to scale up a decoupled application. When the incoming message rate is higher than the consumer rate; you can simply add more workers, receivers, whose job is to work off the queues faster. Breaking the application down into parts will also help you measure and identify the real bottlenecks you might have. As what Martin Fowler said :
The main driver for decoupling capabilities out of a monolith is to be able to release them independently. This first principle should guide every decision that developers make around how to perform the decoupling. A monolithic system often is composed of tightly integrated layers or even multiple systems that need to be released together and have brittle interdependencies.
Independent release. In a monolithic architecture (non decoupled architecture), we might need to deploy the complete application in once, and this might affect critical steps for our service. We do not want the signup (new user on boarding) process to break or be in-responsive for a while just due to a deploy say push notification for like / comment / mention. It’s good to be able to deploy an application’s components separately.
Connecting the Dots
Messaging Broker : RabbitMQ
Consumer : We build our consumer (or people call as worker) with Spring Boot.
Read more about our engineering related to this, here : graph db, XMPP and chatbot.
