SA-101 · Module 1

The 3-Layer Rule

3 min read

Here is a rule I use on every engagement: if a solution requires more than three integration layers, the architecture needs to be rethought — not extended. Three layers is the threshold where complexity transitions from manageable to compounding. Below three, a competent engineer can hold the entire system in their head. Above three, you are relying on documentation that will drift, interfaces that will break, and team knowledge that will walk out the door.

An integration layer is any boundary where one system talks to another. Your application talks to an API — that is layer one. The API talks to a database — layer two. The database triggers a webhook to a third-party service — layer three. Each layer introduces latency, failure modes, and a contract that both sides must honor. The more layers, the more contracts. The more contracts, the more places where a change on one side breaks the other.

The 3-layer rule is not a hard limit. It is a forcing function. When you hit four layers, you stop and ask: is this complexity necessary, or is it an artifact of the path we took to get here? Nine times out of ten, the fourth layer exists because someone bolted on a solution instead of redesigning the interface. The architecture is telling you something. Listen to it.

Do This

  • Count your integration layers before adding another one
  • When you hit four, question whether the architecture needs restructuring
  • Design interfaces that absorb change so layers stay stable
  • Treat each layer boundary as a contract with explicit expectations

Avoid This

  • Add layers because "we can always refactor later" — you will not
  • Treat integration complexity as a sign of sophistication
  • Assume that more components means more capability
  • Ignore the cost of each additional layer in latency, debugging, and maintenance