Architecture Nugget - January 9, 2025

Hey folks!

Welcome to this week’s Architecture Nugget. I’m Liam, and every week I share some of my best reads about software architecture right here.

Before jumping into the nuggets, let me tell you why I publish both Architecture Nugget and Golang Nugget. After a decade in the industry, I’ve learned something valuable—breadth is just as important as depth.

Early in my career, I was on a roll. I was learning fast, became a team lead sooner than expected, and hopped between jobs a few times to soak up new technologies, team dynamics, and—let’s be honest—a bit more cash. But then, like a Wi-Fi signal in a basement, my growth started to plateau.

The problem? I was just doubling down on what I was already good at. As the saying goes, to a hammer, everything looks like a nail. Sure, I could smash certain types of problems with style, but my toolkit was limited. My awareness of new tools, concepts, and approaches—even those unrelated to my day-to-day work—was embarrassingly narrow.

Think of knowledge as a pyramid. At the top, you have your “known-knowns”—things you know you know. Below that are your “known-unknowns”—things you’re aware you don’t know. And at the bottom, in a vast and slightly terrifying space, are your “unknown-unknowns”—the things you don’t even know you don’t know.

Real growth happens when you expand your “known-knowns” by diving deeper and your “known-unknowns” by casually flirting with new ideas—even if it’s just on a surface level.

So how did this help me? By being aware of more tools, concepts, and ideas—even in a “fun fact I read once” kind of way—I could start connecting dots. Most foundational principles don’t change, and when a tricky challenge appeared, I wasn’t just offering guesses; I was offering informed guesses. Plus, having a broader mental library made me a little more creative—I’d seen a few extra ways to crack the same nut.

Why am I sharing this? Because many of the nuggets I share might not immediately fit into your current puzzle. But someday, when you hit a problem that feels like chewing glass, one of these random tidbits might just save the day.

Happy reading!

1. Single Point of Failure (SPOF) in System Design — A single point of failure (SPOF) is a component in your system that, if it fails, causes the entire system to stop working. Depending on the design, any part could become a SPOF. “Single Point of Failure (SPOF) in System Design” is a short article that discusses the risks SPOFs pose and the steps engineers should take to mitigate them.

2. Snapshot Isolation vs Serializability — There are two levels of transaction isolation in database, snapshot isolation and serialisability. Snapshot isolation allows a transaction to go through if its written data doesn’t intersect with the written data of any committed transaction that started before it.
   Under serialisability, a transaction can only commit if the set of data it reads does not intersect with the set of data written by any committed transaction that started before it.

3. Software Architecture and the Art of Experimentation — It’s not rare to be wrong about an architectural design, and that’s why it’s important to have experiments to test the viability of architectural decisions. This article talks about how Minimum Viable Architectures (MVAs) are experiments that test the technical viability of the MVP.