Building Microservices: Designing Fine-Grained Systems

by Sam Newman

Perhaps the term architect has done the most harm.

this view of the architect leads to some terrible practices. Diagram after diagram, page after page of documentation, created with a view to inform the construction of the perfect system, without taking into account the fundamentally unknowable future. Utterly devoid of any understanding as to how hard it will be to implement, or whether or not it will actually work,

we should think of our role more as town planners than architects for the built environment.

One person’s principles are another’s practices.

When services are loosely coupled, a change to one service should not require a change to another.

We want related behavior to sit together, and unrelated behavior to sit elsewhere.

Prematurely decomposing a system into microservices can be costly, especially if you are new to the domain. In many ways, having an existing codebase you want to decompose into microservices is much easier than trying to go to microservices from the beginning.

When you start to think about the bounded contexts that exist in your organization, you should be thinking not in terms of data that is shared, but about the capabilities those contexts provide the rest of the domain.

I called this onion architecture, as it had lots of layers and made me cry when we had to cut through it.

Famously, the first of the fallacies of distributed computing is “The network is reliable”. Networks aren’t reliable.

Postel’s Law (otherwise known as the robustness principle), which states: “Be conservative in what you do, be liberal in what you accept from others.”

For passwords, you should consider using a technique called salted password hashing

Badly implemented encryption could be worse than having none,

Timeouts

Circuit Breakers

Bulkheads

Isolation

Idempotency

Scaling

Splitting Workloads

Spreading Your Risk

Load Balancing

Worker-Based Systems

Scaling Databases

I often see people changing database technology when they start hitting limits on how easily they can scale their existing write volume. If this happens to you, buying a bigger box is often the quickest way to solve the problem, but in the background you might want to look at systems like Cassandra, Mongo, or Riak to see if their alternative scaling models might offer you a better long-term solution.

Caching

CAP Theorem

“Friends don’t let friends write their own crypto”

“Friends don’t let friends write their own distributed consistent data store.”