Tweets about Software Development, Design, and Architecture.
Founder and CEO of NServiceBus. He/Him.
TheSoftwareSimplist@threads
@udidahan@hachyderm.io
Mar 9, 2023 • 19 tweets • 4 min read
Another question I sometimes get is about Document-Oriented Messaging.
This is where the messages don't represent either commands or events, but rather a "document", which is essentially just a bunch of data.
Think of the various government/bank forms that had sections on them like "for office use only".
Feb 23, 2023 • 8 tweets • 3 min read
Another common mistake devs make with REST and CQRS is not differentiating between "data on the outside vs data on the inside", to use @PatHelland terminology:
Think of your system like a Content Management System.
This is the context in which REST came about. The internet is essentially a giant CMS.
Feb 22, 2023 • 4 tweets • 1 min read
Another question came my way, this time about entity-centric REST.
In short, don't do it.
Clients will have to do crappy round trips for joins. GraphQL helps with that.
But when it comes to multi-entity updates/inserts? You don't have transactions. That's going to be trouble.
"That's fine, we'll give them `begin tx` & `end tx` operations as well."
Feb 19, 2023 • 14 tweets • 3 min read
Another question I got was:
What are the disadvantages of using "backend for frontend" instead of a composite UI?
For those of you who might have forgotten, we used to call this "backend for frontend" thing something else:
3-tier architecture
Feb 19, 2023 • 6 tweets • 1 min read
Here was one of the questions from my AMA:
Even services built around capabilities, like "Catalog" & "Warehouse" often need same data (eg Product name).
Is there a rule of thumb whether to duplicate data via rich events or to pull data when needed (via synchronous API calls)?
This is a common mistake with services, thinking of them as physical constructs rather than logical ones.
Sep 18, 2022 • 9 tweets • 2 min read
It's tricky to have developers consistently write correct idempotent code that involves both database work and message emitting.
Let's say you put the message emit code after the DB transaction completes. But occasionally the process crashes right between the two...
Because you have retries set up correctly by your infrastructure (right?), the code gets invoked again.
Because you've written your code to be idempotent, you're checking in the database to see whether you've already done the work before doing it again (right?)
Aug 21, 2022 • 5 tweets • 2 min read
As event-driven architecture continues to gain in popularity, I feel the need to remind folks about the risks of coupling caused by sharing raw business data via events, often occurring with noun-oriented services (like User, Product, Order, etc).
Unfortunately, I see this approach of "over sharing" happening quite a lot around Kafka.
People are leaning far too heavily on just one architectural style, and not using other complementary architectural styles nearly enough.
But, when all you have is a hammer...
Dec 20, 2021 • 7 tweets • 1 min read
Have you ever had a 3rd party webservice go down and cause a flood of errors in your system?
Yeah, I thought so.
So now, on top of the regular error handling in NServiceBus that makes sure that you can recover from those errors without any data loss, we've made things that extra little bit better...
Feb 6, 2019 • 10 tweets • 3 min read
I've been asked my thoughts about Netflix Conductor - a microservices orchestrator: medium.com/netflix-techbl…
This is probably connected to my earlier thread recommending against orchestration as an approach for complex business systems:
The main thing I'd like to note from the Netflix Conductor article is this:
Jan 21, 2019 • 9 tweets • 2 min read
Seriously, can we stop with the flight/hotel/rental-car example for transactions and "distributed sagas" already? I mean, if you couldn't get a rental car, would you really want your flight reservation to be cancelled (known as compensation)? Of course not - it's ridiculous.
There are much fewer cases where the business world requires rollbacks/compensation than technical people would like to believe.
Apr 3, 2018 • 5 tweets • 2 min read
Did you know that in #SQS you can only delay the delivery of a message by at most 15 minutes?
If you wanted to use messaging for scheduling business activities overnight, end-of-week, or end-of-month, that can be a problem.
If you're using NServiceBus on top of SQS, we've solved that problem for you. By combining FIFO queues in #AWS with the natural delayed delivery of SQS, and appropriately bouncing messages between them, we can support arbitrarily long times.
On the question of how team structures align with service boundaries, something we've been experimenting with (quite successfully) is a less-strict division...
There are "squads" that have cross-functional representation for prioritization, risk-assessment and mitigation, and other "architectural" concerns, but the people on these squads take part in other structures as well.
