DEV Community: Vinayak Savale

Day 6 – Guaranteeing Message Ordering in Azure Service Bus

Vinayak Savale — Sun, 14 Sep 2025 11:24:12 +0000

In distributed systems, order matters. Imagine:

A banking system where withdrawal happens before deposit 🏦

An order system where “Order Shipped” comes before “Order Placed” 📦

👉 Without proper message ordering, business logic breaks.

🔹 The Challenge
By default, Azure Service Bus does not guarantee strict ordering across all consumers. Multiple consumers process messages in parallel, which can lead to out-of-order execution.

So, how do we enforce FIFO (First-In-First-Out) processing when it matters?

🔹 Solution: Message Sessions
Azure Service Bus introduces Message Sessions to handle ordered processing.

Messages are grouped using a SessionId.

Service Bus ensures that all messages in a session are delivered in order.

Only one receiver processes a given session at a time.

✅ Example Use Case
👨👩👧 E-commerce Order Processing

All messages related to Order123 (Created → Packed → Shipped → Delivered) share the same SessionId.

Service Bus guarantees these events are processed in sequence.

🔹 Key Benefits
✔ Enforces FIFO processing within a session. ✔ Keeps related messages together. ✔ Avoids complex custom ordering logic.

🔹 Best Practices
Use SessionId for grouping logically related messages.

For high throughput, distribute load across multiple sessions.

Monitor for long-lived sessions that might block processing.

🔹 Wrapping Up
Message Sessions in Azure Service Bus are the key to achieving reliable message ordering. They ensure business events occur in the correct sequence, keeping workflows consistent and predictable.

💬 Do you have scenarios where ordering was critical? How did you solve it in your systems?

Day 5 – Ensuring Message Idempotency with Duplicate Detection in Azure Service Bus

Vinayak Savale — Sun, 14 Sep 2025 11:20:39 +0000

In distributed systems, duplicate messages are inevitable. Network retries, client resends, or failover scenarios can cause the same message to be delivered multiple times.

👉 But in business workflows like payment processing or order creation, duplicates can be disastrous.

This is where Duplicate Detection in Azure Service Bus comes into play.

🔹 What is Duplicate Detection?
A built-in idempotency mechanism in Service Bus.

Detects and discards messages with the same MessageId if received within a configured time window.

Saves developers from building complex deduplication logic at the application level.

🔹 How It Works
Enable Duplicate Detection when creating the Queue/Topic.

Set a Duplicate Detection History Time Window (from 20 seconds up to 7 days).

Service Bus maintains a record of MessageIds within that window.

If a new message with the same MessageId arrives → it is ignored.

✅ Example Use Case
💳 Payments System

User clicks “Pay” twice by mistake.

Both requests send a message with the same TransactionId.

Duplicate Detection ensures only one message is processed, preventing double charges.

🔹 Enabling Duplicate Detection in .NET

🔹 Key Benefits
✔ Prevents double processing of messages.

✔ Reduces risk of financial or logical inconsistencies.

✔ Simple configuration → no need for custom deduplication storage.

🔹 Best Practices
Always set a MessageId when sending messages.

Choose the right time window based on business needs.

For critical systems → combine with idempotent application logic for extra safety.

🔹 Wrapping Up
Duplicate Detection is one of the simplest yet most powerful features in Azure Service Bus. It protects your system against message duplication, ensuring data integrity and reliable workflows.

In Day 6, we’ll explore Message Ordering in Azure Service Bus — how to make sure messages are processed in the sequence they were sent.

💬 Have you faced issues with duplicate events in your applications? How did you solve them?

Day 4 – Handling Failures with Dead-Letter Queues (DLQ) in Azure Service Bus

Vinayak Savale — Sun, 14 Sep 2025 11:18:31 +0000

Even in the most reliable systems, not every message can be processed successfully. 👉 What happens to those “poison messages”?

This is where Dead-Letter Queues (DLQs) come in.

🔹 What is a Dead-Letter Queue?
A sub-queue attached to every Queue or Topic Subscription in Azure Service Bus.

Stores messages that cannot be delivered or processed successfully.

Prevents endless retries or message loss.

🔹 Common Reasons Messages Go to DLQ
✔ Message exceeds TTL (Time-To-Live).

✔ Message is too large.

✔ Max Delivery Count exceeded (message kept failing processing).

✔ Explicit dead-lettering by application.

✅ Real-World Example
Imagine a payment processing system:

A malformed message without PaymentId keeps failing.

Instead of blocking the queue forever, it moves to DLQ for later inspection.

This ensures:

Healthy messages keep flowing.

Faulty messages can be debugged.

🔹 Accessing DLQ in .NET

🔹 Key Benefits of DLQ
✔ Reliability – Messages aren’t lost.

✔ Debugging – Root cause analysis of failed messages.

✔ Isolation – Poison messages don’t block valid ones.

🔹 Best Practices
Monitor DLQ regularly → Don’t let it overflow.

Automate processing → Create a retry mechanism.

Alerting → Set up Azure Monitor alerts for DLQ growth.

🔹 Wrapping Up
Dead-Letter Queues are your safety net in message-driven systems. They ensure your application remains resilient and messages are never silently lost.

In Day 5, we’ll explore Duplicate Detection in Azure Service Bus — how to prevent the same message from being processed multiple times.

💬 How are you handling poison messages in your systems? Do you rely on DLQ or custom error handling?

Azure #ServiceBus #DotNet #Messaging #DeadLetterQueue #CloudComputing #Microservices #Resilience #SystemDesign #ErrorHandling

Day 3 – Message Sessions & Ordering in Azure Service Bus with .NET

Vinayak Savale — Sun, 14 Sep 2025 11:16:30 +0000

When dealing with distributed systems, one challenge that often comes up is:

👉 How do we ensure that related messages are processed in the correct order?

Azure Service Bus solves this problem with Message Sessions.

🔹 What Are Message Sessions?
A Message Session in Service Bus is like a conversation thread that groups related messages together.

Each message has a SessionId.

All messages with the same SessionId are delivered to the same receiver.

Ensures FIFO (First-In, First-Out) ordering within that session.

Useful when you have stateful processing.

✅ Real-World Example
Imagine an e-commerce order system:

Each order may generate multiple messages (Order Placed, Payment Processed, Order Packed, Shipped).

You need all messages for OrderID=12345 to be processed in order.

👉 By assigning SessionId = OrderID, Service Bus guarantees that all events of the order are processed sequentially.

🔹 Enabling Sessions in .NET

🔹 Key Benefits of Message Sessions
✔ Message Ordering – FIFO for related messages.

✔ Stateful Processing – Sessions can maintain state.

✔ Concurrency Control – Different sessions can be processed in parallel.

🔹 When to Use Message Sessions?
Order Processing (all events for one order go together).

Chat Applications (all messages from one conversation thread stay ordered).

Workflow Management (step-by-step sequences per workflow).

🔹 Wrapping Up
Message Sessions make Azure Service Bus powerful for real-world, stateful workflows. They ensure messages that belong together stay together and are processed in order.

💬 Have you used Message Sessions in your projects, or do you rely more on stateless consumers?

Day 2 – Queues vs Topics in Azure Service Bus with .NET

Vinayak Savale — Sun, 14 Sep 2025 11:12:53 +0000

When building distributed applications, one of the most important design decisions is how services will communicate.

Azure Service Bus gives us two powerful messaging patterns: Queues and Topics. While they might seem similar at first, they serve very different purposes depending on the scenario.

In this article (Day 2 of the series), let’s break down the differences, real-world use cases, and .NET implementation for both.

🔹 Azure Service Bus Queue
A Queue is a point-to-point communication channel:

One sender → One receiver

Messages are stored until a receiver picks them up.

Processed in FIFO (First-In, First-Out) order.

👉 Use Queues when you want to ensure only one consumer processes a message.

✅ Real-world example:
An order processing system where each order should be handled by one service instance.

🔹 Azure Service Bus Topic & Subscriptions
A Topic is like a broadcast system.

One sender → Multiple receivers

A message is sent to the Topic, and multiple Subscriptions can receive it.

Each subscription can apply filters (only get the messages it cares about).

👉 Use Topics when you want multiple services to react to the same event.

✅ Real-world example:
A payment event:

Billing system → logs the payment.

Notification system → sends receipt email.

Analytics system → updates dashboards.

🔹 Code Example in .NET

🔹 Wrapping Up
Queue = One-to-one communication.

Topic = One-to-many communication.

Both are durable, scalable, and reliable messaging patterns in Azure Service Bus.

👉 The right choice depends on whether your message should go to one service or many services.

💬 Which messaging pattern have you used more in your projects — Queues or Topics?

Day 1 – Introduction to Azure Service Bus in .NET

Vinayak Savale — Sun, 14 Sep 2025 11:02:33 +0000

In today’s world of distributed systems and microservices, one of the biggest challenges is ensuring reliable communication between applications.

That’s where Azure Service Bus comes into play. It’s a fully managed enterprise messaging service that helps: ✅ Decouple applications ✅ Improve scalability ✅ Build resilient communication pipelines

🔹 What is Azure Service Bus?
Think of Service Bus like a post office for your applications:

Applications send messages (letters) to Service Bus.

Service Bus stores them securely until the receiving service is ready.

Applications receive messages when they can process them.

This design provides: ✔ Loose coupling ✔ Fault tolerance ✔ Better scalability

🔹 Core Concepts
Namespace → A logical container grouping queues & topics.

Queues → Point-to-point messaging (one sender → one receiver). Follows FIFO order.

Topics & Subscriptions → Publish/Subscribe model. A single message can reach multiple subscribers. Perfect for event-driven systems.

Message → The basic unit of communication, including payload + metadata.

🔹 .NET Integration Example

Here’s how simple it is to send a message to a Service Bus queue using Azure SDK for .NET:

Minimize image
Edit image
Delete image

Add a caption (optional)
🔹 Real-World Applications
🛒 Order Processing Systems → Decouple order placement from payment & inventory.

📡 IoT Devices → Buffer messages from millions of devices before processing.

⚡ Event-driven Microservices → Publish once, let multiple services react.

🔄 Legacy Integration → Connect old on-premise apps with modern cloud systems.

🔹 Wrapping Up
Azure Service Bus provides the foundation for building reliable, scalable, and decoupled systems in the cloud.

Today we covered: ✔ What Service Bus is ✔ Why it’s important ✔ Core concepts (namespace, queues, topics) ✔ A simple .NET integration example

💬 What’s your experience with messaging systems? Have you worked with Azure Service Bus, RabbitMQ, or Kafka? Drop your thoughts below 👇

Basic Authentication and Authorization

Vinayak Savale — Wed, 20 Mar 2024 09:58:15 +0000

In the .NET framework, authentication and authorization are two important processes that help ensure the security of applications and their data.

"Authentication" is the process of verifying the identity of a user, device, or system. In the context of the .NET framework, it involves confirming that the person or thing claiming to be a certain party is indeed that party. This is usually done through logins, passwords, or other means of verification.

"Authorization," on the other hand, is the process of deciding what actions a user, device, or system is allowed to perform. This is typically determined by the results of the authentication process. If a user has been authenticated, authorization dictates what they can do within the application.

The Identity Provider (IP) is a component in the .NET framework that handles these processes. It helps manage users, their associated data, and the claims they make, which are used to make authorization decisions.

Here's a simple example of how this might work in a .NET application:

A user attempts to log in to a website using their username and password.

The application checks these credentials against its records (perhaps using ASP.NET Identity).

If the credentials are valid, the user is authenticated and their identity is established.

Once authenticated, the application checks its authorization rules to see what actions the user is allowed to perform. This information might be stored in a database or determined based on the user's role or other attributes.

If the user is authorized to perform a certain action, they are allowed to proceed. Otherwise, their request is denied.

In layman's terms, authentication is like showing your ID at a nightclub to prove you're old enough to enter, and authorization is figuring out if you're on the guest list or if you can actually dance on the tables.

Trust Issues with setTimeout()! 💔 setTimeout Interview Question

Vinayak Savale — Mon, 01 Feb 2021 16:35:21 +0000

setTimeout has trust issues! 💔

setTimeout(function a() {
   console.log("Example");
}, 5000);

If you execute the above program it might take 5 sec or more than 5 sec to log the result of function a. Yes, you read it right because it all depends on the callstack.

To prove the above statement we will see one example:
Example 1:

console.log("Start");

setTimeout(function a() {
   console.log("Callback");
}, 5000);

console.log("End");

let startDate = new Date().getTime();
let endDate = startDate;

// Added 10 sec timer
while (endDate < startDate + 10000) {
   endDate = new Date().getTime();
}

console.log("While expires");

Guess what will be the output of the above program. You might be thinking that first in the console Start will get print then End will get print. Which is absolutely right! After that you might be thinking setTimeout function a will execute after 5 sec but the answer is NO. Because at first GEC (Global execution context) is created and it adds in callstack as it will take 10 sec to run GEC code and setTimeout will get registered in Callback Queue and event loop will call setTimeout function only when callstack gets empty so that's why it will execute after 10 sec. So that's how the whole concurrency model works.

Output:

Start
End
While expires
Callback

Take one more example to understand the concept.
Example 2:

console.log("Start");

setTimeout(function a() {
   console.log("Callback");
}, 0);

console.log("End");

Now guess what will be the output of the program. In the above example, you can see setTimeout will be in callback queue and it will be called only after the callstack gets empty which will be after Start and End print in the console.

Output:

Start
End
Callback

You must be thinking who the hell writes 0 sec in setTimeout. But you can write 0 sec in setTimeout in particular condition like if you want to execute particular code after all function gets executed as setTimeout function will be in callback queue which will be executed once callstack gets empty. In such a condition you can use 0 sec in setTimeout.

Even I was not aware of this till I watched the Namaste javascript series by Akshay Saini. Believe me, friends many senior developers will fail to answer correctly the output of the above examples.

So, This is my first post do let me know in the comment section if you really amazed by this concept.