Created a draft of messaging-first-architecture #98
Conversation
immo-huneke-zuhlke
left a comment
immo-huneke-zuhlke
left a comment
There was a problem hiding this comment.
I love this - it's at just the right level for general technical readership, contains practical advice and clarifies the thinking behind using messaging as opposed to synchronous APIs.
|
|
||
| ## 2. Why & When Messaging-First? | ||
|
|
||
| In most systems I’ve worked on, HTTP APIs were the go-to service A calls service B, often in a tightly coupled chain. That works fine for many workflows, especially when you need quick, direct responses. But in a recent project, we leaned into a messaging-first approach using Azure Service Bus. Instead of services calling each other directly, they communicated through messages and that changed a lot. |
There was a problem hiding this comment.
This first sentence looks a bit non-grammatical. How about:
In most systems I’ve worked on, HTTP APIs were the go-to architectural option, in which service A calls service B, often in a tightly coupled chain.
There was a problem hiding this comment.
Changed to "In most of the systems I’ve worked on, HTTP APIs were the standard architectural approach, where service A calls service B often in a tightly coupled sequence."
|
|
||
| That said, putting messaging at the center of your system does mean you have to take it seriously. | ||
| Things like Dead Letter Queues, lock timeouts, or message retries can become blind spots if you’re not monitoring them properly. | ||
| Team had to invest in observability early; logs, alerts, correlation IDs to make sure we weren’t flying blind. |
There was a problem hiding this comment.
Missing article. Use "The team" instead of just "Team".
| Things like Dead Letter Queues, lock timeouts, or message retries can become blind spots if you’re not monitoring them properly. | ||
| Team had to invest in observability early; logs, alerts, correlation IDs to make sure we weren’t flying blind. | ||
|
|
||
| So yes, Service Bus is central. But with the right setup, it’s not fragile. In fact, it ended up being reliable parts of the stack. |
There was a problem hiding this comment.
Is it one part or several parts? This sentence doesn't quite make sense. How about:
In fact, it ended up being one of the most reliable parts of the stack.
Or even
In fact, it ended up being the most reliable part of the stack.
There was a problem hiding this comment.
Yes right , changed to "In fact, it ended up being the most reliable part of the stack."
| - Include message IDs and payloads (truncated!) in logs for traceability. | ||
| - Track processing times and delivery counts to detect slow consumers. | ||
|
|
||
| Don’t treat observability as an afterthought. When a message fails silently, it’s hard to debug unless you’ve wired in visibility. |
There was a problem hiding this comment.
Perhaps it's worth adding a note of caution about spoiling the ship for a ha'porth of tar - some product managers believe that they can save money by eschewing the use of logging, telemetry and analytics, but these savings are usually outweighed by the wasted effort of tracking down the problems that inevitably occur.
There was a problem hiding this comment.
Ohh really like it, I want to use that line :)
Added
Don’t treat observability as an afterthought - it’s a classic case of spoiling the ship for a ha’porth of tar. Skimping on logging and telemetry might save a little now, but it'll cost far more when failures strike and you're flying blind.
|
|
||
| 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. | ||
|
|
||
| System can be hybrid. It’s not one or the other. It’s about picking the right tool for the job. |
There was a problem hiding this comment.
System --> Systems?
@immo-huneke-zuhlke Thank you so much for reviewing my blog post — your suggestions were really helpful and made a big difference. |
tispBe
left a comment
tispBe
left a comment
There was a problem hiding this comment.
super nice article. well written and relevant. Thanks a lot for this contribution!
Maybe it could benefit from some "code nuggets" and "config excerpts". Up to you though.
Apart from that, I have requested only two small editorial changes for the hashnode import.
| saveAsDraft: true | ||
| hideFromHashnodeCommunity: false | ||
| publishAs: gayatri-potawad | ||
| tags: |
There was a problem hiding this comment.
Please ensure that the tags are supported by hashnode.. Additionally, it should be a comma-separated list of slugs (see in the published folder for reference of already published articles)
There was a problem hiding this comment.
The local validation will issue a warning that a list is expected but you've supplied a string. Apparently this should be ignored.
| @@ -0,0 +1,138 @@ | |||
| --- | |||
| title: "Messaging-First Architectures: Resilient Systems with Azure Service Bus" | |||
| date: "2025-06-24" | |||
There was a problem hiding this comment.
please remove the date. it will be added to the article automatically.
3 participants
No description provided.