To be clear: I do not think we should actually forget technical debt. Also, this is not the nth post discussing if “debt” is an appropriate metaphor. I do not have a strong opinion regarding the metaphor. My point is rather that I realized in a recent discussion that in the end, it is not so much about technical debt but rather about something else, and I wanted to share the thought.

Recently, AWS experienced one of its rare partial outages. Its DynamoDB service experienced a disruption in the US-East-1 region that could be tracked down to a latent race condition in the DynamoDB DNS management system which caused the disruption. A comprehensive post-event summary describing the outage, its cause and the resulting effects can be found here.

In the previous post we discussed what eventual consistency actually means and why we sometimes need to favor eventual consistency over strong consistency. We also saw that most of the time we will not perceive any differences between eventual and strong consistency if set up properly. The differences only become apparent if the system encounters adverse conditions like, e.g., a network partition, loss of a node, or alike.

Recently I saw a skeet on Bluesky:

In the previous post, we started to discuss a specific type of coupling, the coupling between processes in a distributed system. We discussed the fallacy that loose technical coupling, i.e., using a message-based communication style is sufficient to ensure loose coupling between processes. We learnt that instead we need to implement loose coupling at a technical and a functional level to actually become loosely coupled.