Revisiting a book review I wrote in Korean last year, I decided to rewrite it to share my thoughts with a new audience. Although I'm not an architect, I encounter intricate decisions that shape the software as a software engineer. Have you ever faced a complex architectural problem with no clear solution? This book tells the story of engineers who constantly face new and unsolvable problems, striving to make the best possible choices.

Why does a technologist like a software architect present at a conference or write a book? Because they have discovered what is colloquially known as a “best practice,” ... technologists write books when they have figured out a novel solution to a general problem and want to broadcast it to a wider audience. But what happens for that vast set of problems that have no good solutions? Entire classes of problems exist in software architecture that have no general good solutions, but rather present one messy set of trade-offs cast against an (almost) equally messy set.

... Architects may have wondered why so few books exist about architecture compared to technical topics like frameworks, APIs, and so on. Architects rarely experience common problems but constantly struggle with decision making in novel situations. For architects, every problem is a snowflake. In many cases, the problem is novel not just within a particular organization but rather throughout the world. No books or conference sessions exist for those problems!

— p. 1

Content and Structure

This book is an advanced sequel to "Fundamentals of Software Architecture: An Engineering Approach," providing an in-depth guide to help measure trade-offs when designing distributed architectures in practice. It offers guidelines to consider when pulling things apart, such as code volatility, scalability, and maintainability, as well as guidelines for putting things back together, such as transactions, workflows, and shared code. It provides detailed methods for analysing and finding the balance between the two.

Furthermore, it presents transactional saga patterns that can be selected according to the situation. These patterns are generated by the combination of three coupling forces: communication, consistency, and coordination. The subtitle "The Hard Parts" reflects how "hard" it is to make architectural decisions among these various forces, and once the structure is set, it becomes "hard" to change.

The book is divided into two main parts: Part 1, "Pulling Things Apart," and Part 2, "Putting Things Back Together." In Part 1, it focuses on "structure," helping to understand the components that make up the architecture by separating them piece by piece. In Part 2, it focuses on "communication," allowing readers to see how the components interact and operate as a single unit.

Lastly, through a story within the book called "The Sysops Squad Saga," it allows readers to glimpse how to communicate and persuade stakeholders about technical choices. By carefully reading the accompanying Architecture Decision Records (ADRs) in the story, you can also learn how to effectively document architectural decisions.

Key Takeaways

If I had to pick the most useful aspect, it would be the abundant diagrams. The concepts are conveyed very clearly through illustrations, making it easy for even those with little background in architecture to understand. The various tables summarising data and trade-offs also facilitate comparisons between patterns, helping to weigh pros and cons.

Another point that shifted my thinking was the acceptance of redundancy. There's a famous principle called DRY (Don't Repeat Yourself). While I didn't take this literally, my basic mindset was that less redundancy leads to better code. But I was surprised to learn that in distributed architecture, redundancy is actually encouraged. Of course, allowing redundancy brings synchronisation issues, but in distributed architecture, coupling can have worse impacts than redundancy, so they even advise the reverse with WET (Write Every Time or Write Everything Twice).

I had thought that separation and reuse were the best solutions for various problems, such as separating view and logic, client state and server state, and component reuse. However, thanks to this book, I feel reassured knowing that when facing difficulties in the current structure, I can consider "distribution" as an alternative solution.

When reading development books, you often come across the phrase "There is no silver bullet." This book particularly warns against this point because there's no magical architecture that solves all problems. Just as refactoring should be a part of development rather than separate from it, it emphasises that by analysing your system and repeatedly designing it, you can gradually create a better architecture.

Recommended For

• Those who feel the limitations of their current architecture and want to know the pros and cons of various architectures
• Those who want to learn how to evaluate trade-offs by identifying coupling and analysing single point of failure (SPOF)
• Those who want to learn how to present criteria that can assist decision-making to non-technical stakeholders

An Aside

I thought that forming a team might be just as challenging and fraught with trade-offs as making a distributed architecture work properly. Each team member has their own knowledge (database) and provides specialised functions (services), and the organisation operates as these various people communicate directly (synchronously) or via messaging tools (asynchronously). Interestingly, just like filling a team with superstars doesn't guarantee victory, the right combination suited to the task is important.

If you've read it, I'd love to hear your thoughts. Please feel free to get in touch with your perspectives on the book or any questions you might have.