coding is an art form
In messaging systems, not every message can be processed successfully. Some messages may be invalid, expired, or cause errors in consumers. Instead of losing these messages, RabbitMQ provides a feature called the Dead Letter Queue (DLQ). DLQs allow you to capture, inspect, and handle failed messages safely. By default, any message that is rejected with…
RabbitMQ is one of the most popular message brokers for building distributed systems. It allows applications to communicate asynchronously by sending and receiving messages through queues. At the heart of RabbitMQ is the concept of an exchange, which decides how messages flow from producers (publishers) to consumers. This article explains RabbitMQ’s most common exchange types…
One of the main reasons people use RabbitMQ is reliability. In many systems, losing a message is not acceptable. Imagine if an order is placed in an e-commerce system but disappears before the payment service sees it, that would be a big problem. RabbitMQ offers three important features to ensure reliable messaging: Acknowledgments, Durability, and…
In distributed systems, maintaining message ordering is crucial for ensuring data consistency and correctness. While Apache Kafka is well-known for its strong ordering guarantees, NATS JetStream offers a powerful alternative with the right architectural approach. This article explores how to implement Kafka-like message ordering in NATS using partitioned consumers and lease-based coordination.
In the last article, we talked about the NATS Key-Value Store (KV), which is great for lightweight configuration and state management. But what if you need to store something larger, like a file, image, or binary data? For that, NATS provides the Object Store, also built on top of JetStream.
So far, we’ve looked at different messaging patterns in NATS like Publish–Subscribe, Request–Reply, and Queue Groups. Those patterns are great for communication, but sometimes you need a way to store small pieces of state that services can read, update, or watch for changes. NATS provides this through its Key-Value Store (KV), built on top of…
In the previous articles, we looked at Publish–Subscribe and Request–Reply patterns in NATS. Pub/Sub is great for broadcasting messages to many subscribers, while Request–Reply is perfect for one-to-one communication. But what if you want to distribute messages across a group of workers so that only one of them processes each message? This is where Queue…
In the previous article, I explained the Publish–Subscribe pattern in NATS, which is great for broadcasting messages to many subscribers. But sometimes you need a different style: you want to send a message and get a response back. This is where the Request–Reply pattern comes in.
In the previous article, I wrote an overview of NATS and NATS JetStream. Before we go deeper into advanced topics like scalability and reliability, it’s important to understand the most common messaging pattern in NATS: Publish–Subscribe. What is Publish–Subscribe? Publish–Subscribe (or pub/sub) is a way of sending messages where: It’s a decoupled system: the publisher…