Good coding is always a good start to a good product but writing code is not sufficient to build a good product. If you are technical and thinking I can code and I can develop a product. That’s true. You can develop a product but without help of other technologies your product will be just a product not a good product.
Now, you are thinking what is a good product then, right?
A good product is a product which provides a good experience to your customers, not for you. Most of the startups develop a product for self satisfaction only that means they are liking it and don’t care about customers whether they like it or not. If you are solving a customer’s problem then you have to keep in mind customers always what they think, what they like, what they love and what are their pain points.
One day I was designing a system architecture for one of a marketing team’s requirements. Suddenly I got a message on slack to join a meeting in the boardroom. I was not aware of the meeting schedule. It was a random meeting. It’s a culture of startups. You never know when you called for a meeting or when the requirements got changed immediately after an hour. You can understand it good or bad but this is the beauty or culture of startups.
I went to the boardroom to join the meeting and I got to know that the meeting is related to user experience with the marketing team. How we can improve user experience for a landing page for an upcoming deal. Usually on every Friday we run a deal for some accessories to engage with customers. The previous user experience of the deal was not good. How we can improve the user experience was the primary concern of the marketing team. They requested me to please help us to improve the user experience as we are expecting a large volume of traffic for this deal.
I promised and replied to them please go and run your campaigns. I assure you this time user experience will be good. Let me sit with my tech team and discuss the concern where and what is the problem. It took just 5 minutes and we ended the meeting.They returned back happily.
Why?
Because we just discussed the problem and gave an assurance to fix the problem by improving the user experience for the next time. They are not technical people. Then what’s the point to go in deep of technical things. What and how we will fix the problem. There was no point in taking 30–40 minutes for the meeting while I know where the problem is.
After lunch I sat with the technical lead of the concern team to understand the problem and figure out the root cause of the problem. I found that the task was assigned to a junior developer previously and she did based on her experience.
What wrong did she do?
She wrote the code nicely but did not implement the queuing mechanism. Based on her experience she did their best but she was not aware about what are the other ways to improve the user experience.
She was did four things in her code base
- Capturing the user information and storing it in database
- Sending a email
- Sending a SMS
- Insertion the emails in to an another table for newsletter purpose
There was nothing wrong with her code but that was not good as per user experience.
Why?
Because she was doing all the things in a single function and was not releasing the customer until or unless all the four tasks were not completed. This was causing a problem with user experience. The whole process was taking 10–15 seconds. It’s too much for customers. A customer does not want to wait for a long time.
Now you would be wondering how we can release the customer quickly, right?
Yes, all the time we should keep in our mind how we can release the customer quickly after taking the required information. What you are doing in the background customer doesn’t care. Whether you are using redis, elastic, rabbitmq or kafka etc. Customer really doesn’t care at all.
We can easily release a customer by the help of the message queuing techniques.There are several pub/sub technology tools available, both open-source and commercial. Here are some examples:
- Apache Kafka: An open-source distributed streaming platform that can be used for pub/sub messaging, stream processing, and storage. Kafka is designed for high-throughput, low-latency messaging and is widely used in real-time data processing applications.
- RabbitMQ: An open-source message broker that can be used for pub/sub messaging, request/reply, and work queues. RabbitMQ supports a wide range of messaging patterns and protocols and is known for its reliability and performance.
- Amazon Simple Notification Service (SNS): A cloud-based pub/sub messaging service provided by Amazon Web Services (AWS). SNS can be used to send messages to multiple recipients using a variety of protocols, including HTTP, email, and SMS.
- Google Cloud Pub/Sub: A cloud-based pub/sub messaging service provided by Google Cloud Platform. Pub/Sub can be used to send messages between applications and services, and supports push and pull delivery methods.
- NATS: An open-source messaging system that supports pub/sub messaging and request/reply. NATS is known for its high performance and scalability, and is often used in cloud-native and microservices architectures.
- Apache Pulsar: An open-source distributed pub/sub messaging system that can be used for streaming, messaging, and storage. Pulsar is designed for scale and performance, and supports multiple messaging patterns and delivery semantics.
We can use anyone from these based on our team expertise or business use case. All provide an asynchronous environment for customers through the use of messaging queues. In a traditional synchronous environment, a client sends a request to a server and waits for a response. This can result in delays and performance issues, especially when dealing with large volumes of requests or slow servers.
By using these tools, clients can send requests to a messaging queue, and the server can respond asynchronously when it is ready. The client does not need to wait for a response and can continue with other tasks. This decouples the client from the server and provides a more efficient and scalable architecture.
How a Message Broker Techniques Works
We can easily understand how these message broker technique works with a help of the following diagram as
Suppose a customer places an order. Give a success response to the customer immediately like “Hey, Congratulations your order has been placed successfully. Thanks for being with us.” After capturing the order details and getting the order id, put the order id into a message broker to process the other things to notify him with other ways like email, sms or push notification etc. This way we can give a good user experience without waiting for page load or failures.
I hope this article will help you to understand about basics how a message broker technique works and why its important to improve a user experience.
Conclusion
Writing a good code is a good foundation of a product. But to build a good product various other technologies are used. Caching, Searching and Queuing all three techniques are most important to build a good, fast and scalable product. Different messaging techniques are available to improve a user experience. Kafka and RabbitMQ are most popular open source techniques.