The first fallacy of distributed computing

(This was supposed to go out yesterday, but I made a mistake in how my site software works. Apologies! We’ll be back to our regular flow of content with today’s.)


You can have a second computer once you’ve shown you know how to use the first one. – Paul Barham

For the time being, our computers are subject to the laws of physics, and this has an unfortunate-but-often-left-out-of-tool-vendor-marketing consequence: networks fail.

Believing otherwise is the first fallacy of distributed computing.

This typically manifests as a team finishing an implementation with, say, Kafka and turning it on, only to start noticing weird duplication in their workloads. Examples include duplicate charges to customer accounts, duplicate emails, etc.

In Kafka’s case, the first fallacy implication goes something like:

  1. Network transmissions can get lost
  2. Kafka uses acknowledgement messages to avoid duplication
  3. Acknowledgement messages are network transmissions
  4. Goto 1

Now, “unreliable” does not equal “happens all the time,” which makes this sort of issue difficult to debug and understand. I (and probably your customers!) want you and your teams to understand it, so the next few days will cover how to enable your systems to safely inhabit reality.

For those who want to start googling now, your countermeasure is idempotence.


Like this message? I send out a short email each day to help software development leaders build organizations the deliver value. Join us!


Get the book!

Ready to learn how to build an autonomous, event-sourced microservices-based system? Practical Microservices is the hands-on guidance you've been looking for.

Roll up your sleeves and get ready to build Video Tutorials, the next-gen web-based learning platform. You'll build it as a collection of loosely-coupled autonomous services, developing a message store interface along the way.

When you're done, you'll be ready to contribute to microservices-based projects.

In ebook or in print.