Conway's Law and Its Implications for Microservices Architecture

Overview

Microservices have become a hot topic, but their theoretical foundation can be traced back to Conway's Law, which states that system designs mirror the communication structures of the organizations that create them.

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. – Melvin Conway (1967)

Conway originally wrote about this in a broader context, not limited to software, and the idea was later popularized in Brooks' "The Mythical Man‑Month".

Detailed Introduction to Conway's Law

Mike Amundsen highlights several core principles derived from Conway's original paper:

First Law: Communication dictates design.

Second Law: There is never enough time to do something right, but there is always enough time to do it over.

Third Law: There is a homomorphism between the linear graph of a system and the linear graph of its design organization.

Fourth Law: The structures of large systems tend to disintegrate during development, more so than small systems.

Humans as Complex Social Animals

Communication cost grows quadratically with team size (n(n‑1)/2), which explains why startups keep teams small. The Dunbar number (≈150) also limits the number of stable relationships a person can maintain.

Practical Implications

Eric Hollnagel emphasizes the trade‑off between efficiency and effectiveness, suggesting that when resources are limited, details should be ignored and features dropped.

Problem too complicated? Ignore details. Not enough resources? Give up features. --Eric Hollnagel (2009)

He distinguishes between absolute safety (eliminating all errors) and resilient safety (recovering quickly from errors), a principle that aligns with continuous integration and resilient system design.

Designing Autonomous Sub‑Systems to Reduce Communication Cost

Applying Conway's first law, the structure of a system reflects the organization of its teams. If teams are divided by function (frontend, backend, DBA, ops), the system will be fragmented accordingly. Conversely, organizing teams around business capabilities yields a microservice architecture with clear boundaries and reduced inter‑team communication.

Divide and Conquer

Large organizations naturally split into smaller teams to manage communication overhead, following the fourth law. This leads to microservices being a natural fit for such decentralized structures.

How Conway's Law Justifies Microservices

Key takeaways:

Team communication complexity drives the need for modular, autonomous services.

Clear boundaries and cohesive subsystems lower communication cost.

Iterative, resilient design (MVP, DevOps) aligns with the realities of distributed systems.

Small, cross‑functional teams (≈7‑8 members) are optimal for maintaining high efficiency.

References

Mike Amundsen, “Conway’s Law in Distributed World” (InfoQ).

Conway’s Law – Wikipedia.

Conway’s Law Homepage.