Created a draft of messaging-first-architecture by gayatri-potawad · Pull Request #143 · Zuehlke/software-engineering-corner

gayatri-potawad · 2026-03-09T14:05:56Z

After folder structure changes, needed to open a new PR for #98

have addressed all reviewers' comments from the old PR.

This article is just a kick-starter's info. I will be getting more into these topics and adding config files and code nuggets separately for each part.

I also received a suggestion to add observability more, so I am planning a few more articles on Azure, dead letter queues, and monitoring, etc.

FYI @tispBe

kunman93

I reviewed this article with the help of AI. Otherwise I wouldn't have found this many findings. The next time, let AI review your article and then create a PR.

I also used the em-dash variant without spaces throughtout the article. Both variants are legit.

Also, please review my suggestions carefully, since English is not my first language.

kunman93 · 2026-04-24T08:55:14Z

+---
+
+# Messaging-First Architectures: Resilient Systems with Azure Service Bus 
+


Suggested change

Markdown Style: there's no need to add mutliple lines, since Markdown treats multiple blank lines as one blank line.

kunman93 · 2026-04-24T08:59:50Z

+In one of my previous projects, I worked on a large-scale retail platform where nearly every critical business flow from orders to inventory updates relied on Azure Service Bus. This was my first dive into a messaging-first architecture on Azure. 
+
+This blog is my attempt to capture what I learned and design principles that shaped the system and hopefully help anyone walking a similar path, especially if you’re transitioning from synchronous REST-based APIs to asynchronous messaging. 
+


Suggested change

kunman93 · 2026-04-24T09:01:54Z

+
+In one of my previous projects, I worked on a large-scale retail platform where nearly every critical business flow from orders to inventory updates relied on Azure Service Bus. This was my first dive into a messaging-first architecture on Azure. 
+
+This blog is my attempt to capture what I learned and design principles that shaped the system and hopefully help anyone walking a similar path, especially if you’re transitioning from synchronous REST-based APIs to asynchronous messaging. 


Suggested change

This blog is my attempt to capture what I learned and design principles that shaped the system and hopefully help anyone walking a similar path, especially if you’re transitioning from synchronous REST-based APIs to asynchronous messaging.

This blog is my attempt to capture what I learned and design principles that shaped the system and hopefully help anyone walking a similar path—especially if you’re transitioning from synchronous REST-based APIs to asynchronous messaging.

kunman93 · 2026-04-24T09:02:14Z

+Azure Service Bus is a fully managed enterprise message broker that enables decoupled communication between services using queues and topics. 
+If you’ve worked with something like ActiveMQ, Kafka, or RabbitMQ, a lot will feel familiar, but Azure adds cloud-native features like auto-scaling, integration with Azure Functions, and dead-letter handling. 
+
+


Suggested change

kunman93 · 2026-04-24T09:05:08Z

+## 1. Azure Service Bus 
+
+Azure Service Bus is a fully managed enterprise message broker that enables decoupled communication between services using queues and topics. 
+If you’ve worked with something like ActiveMQ, Kafka, or RabbitMQ, a lot will feel familiar, but Azure adds cloud-native features like auto-scaling, integration with Azure Functions, and dead-letter handling. 


Suggested change

If you’ve worked with something like ActiveMQ, Kafka, or RabbitMQ, a lot will feel familiar, but Azure adds cloud-native features like auto-scaling, integration with Azure Functions, and dead-letter handling.

If you’ve worked with something like ActiveMQ, Kafka, or RabbitMQ, much of this will feel familiar. However, Azure adds cloud-native features like auto-scaling, integration with Azure Functions, and dead-letter handling.

kunman93 · 2026-04-24T11:07:23Z

+If you’re close to the limit, compress the payload or store large data in blob storage and just pass a reference. 
+
+- Lock Timeouts 
+By default, a message lock lasts 30 seconds. If your function or processor takes longer, Azure will think it failed and redeliver the message. We observed implementing lock renewal, increases processing efficiency to avoid duplicate executions. 


Suggested change

By default, a message lock lasts 30 seconds. If your function or processor takes longer, Azure will think it failed and redeliver the message. We observed implementing lock renewal, increases processing efficiency to avoid duplicate executions.

By default, a message lock lasts 30 seconds. If your function or processor takes longer, Azure will assume it has failed and redeliver the message. We found that implementing lock renewal increased processing efficiency and helped avoid duplicate executions.

kunman93 · 2026-04-24T11:11:18Z

+
+## Wrapping Up 
+
+This project really changed the way I think about service communication. Messaging-first isn’t just about queues and topics. It’s about designing for resilience, decoupling, and scale from day one.  


Suggested change

This project really changed the way I think about service communication. Messaging-first isn’t just about queues and topics. It’s about designing for resilience, decoupling, and scale from day one.

This project really changed the way I think about service communication. Messaging-first isn’t just about queues and topics; it’s about designing for resilience, decoupling, and scale from day one.

kunman93 · 2026-04-24T11:12:36Z

+
+But here’s the nuance: messaging-first doesn’t mean messaging-only. 
+
+Some interactions are still best done synchronously like fetching user details for a UI in real time or validating input. The real strength comes from knowing where async fits best: background jobs, cross-system workflows, retries, or anything that shouldn’t block the user. 


Suggested change

Some interactions are still best done synchronously like fetching user details for a UI in real time or validating input. The real strength comes from knowing where async fits best: background jobs, cross-system workflows, retries, or anything that shouldn’t block the user.

Some interactions are still best done synchronously, such as fetching user details for a UI in real time or validating input. The real strength comes from knowing where async fits best: background jobs, cross-system workflows, retries, or anything that shouldn’t block the user.

kunman93 · 2026-04-24T11:13:25Z

+
+Some interactions are still best done synchronously like fetching user details for a UI in real time or validating input. The real strength comes from knowing where async fits best: background jobs, cross-system workflows, retries, or anything that shouldn’t block the user. 
+
+Systems can be hybrid. It’s not one or the other. It’s about picking the right tool for the job. 


Suggested change

Systems can be hybrid. It’s not one or the other. It’s about picking the right tool for the job.

Systems can be hybrid. It’s not one or the other; it’s about picking the right tool for the job.

kunman93 · 2026-04-24T11:14:25Z

+
+Systems can be hybrid. It’s not one or the other. It’s about picking the right tool for the job. 
+
+If you're building distributed systems on Azure, or transitioning from a synchronous mindset like I was, I hope this gives you a good head start. 


Suggested change

If you're building distributed systems on Azure, or transitioning from a synchronous mindset like I was, I hope this gives you a good head start.

If you’re building distributed systems on Azure, or transitioning from a synchronous mindset like I was, I hope this gives you a good head start.

kunman93

I reviewed this article with the help of AI. Otherwise I wouldn't have found this many findings. The next time, let AI review your article and then create a PR.

I also used the em-dash variant without spaces throughtout the article. Both variants are legit.

Also, please review my suggestions carefully, since English is not my first language.

Gayatri P added 2 commits March 9, 2026 19:34

rewritten draft for old pr 98

4677652

updated metadata since article is old but needs to publish now

111b504

kunman93 reviewed Apr 24, 2026

View reviewed changes

		---

		# Messaging-First Architectures: Resilient Systems with Azure Service Bus

		In one of my previous projects, I worked on a large-scale retail platform where nearly every critical business flow from orders to inventory updates relied on Azure Service Bus. This was my first dive into a messaging-first architecture on Azure.

		This blog is my attempt to capture what I learned and design principles that shaped the system and hopefully help anyone walking a similar path, especially if you’re transitioning from synchronous REST-based APIs to asynchronous messaging.

		Azure Service Bus is a fully managed enterprise message broker that enables decoupled communication between services using queues and topics.
		If you’ve worked with something like ActiveMQ, Kafka, or RabbitMQ, a lot will feel familiar, but Azure adds cloud-native features like auto-scaling, integration with Azure Functions, and dead-letter handling.

	By default, a message lock lasts 30 seconds. If your function or processor takes longer, Azure will think it failed and redeliver the message. We observed implementing lock renewal, increases processing efficiency to avoid duplicate executions.
	By default, a message lock lasts 30 seconds. If your function or processor takes longer, Azure will assume it has failed and redeliver the message. We found that implementing lock renewal increased processing efficiency and helped avoid duplicate executions.


		## Wrapping Up

		This project really changed the way I think about service communication. Messaging-first isn’t just about queues and topics. It’s about designing for resilience, decoupling, and scale from day one.


		But here’s the nuance: messaging-first doesn’t mean messaging-only.

		Some interactions are still best done synchronously like fetching user details for a UI in real time or validating input. The real strength comes from knowing where async fits best: background jobs, cross-system workflows, retries, or anything that shouldn’t block the user.


		Some interactions are still best done synchronously like fetching user details for a UI in real time or validating input. The real strength comes from knowing where async fits best: background jobs, cross-system workflows, retries, or anything that shouldn’t block the user.

		Systems can be hybrid. It’s not one or the other. It’s about picking the right tool for the job.


		Systems can be hybrid. It’s not one or the other. It’s about picking the right tool for the job.

		If you're building distributed systems on Azure, or transitioning from a synchronous mindset like I was, I hope this gives you a good head start.

	If you're building distributed systems on Azure, or transitioning from a synchronous mindset like I was, I hope this gives you a good head start.
	If you’re building distributed systems on Azure, or transitioning from a synchronous mindset like I was, I hope this gives you a good head start.

Conversation

gayatri-potawad commented Mar 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kunman93 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kunman93 left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

gayatri-potawad commented Mar 9, 2026 •

edited

Loading