Trade-offs, not "best practice"

The phrase "best practice" is often applied without question, but a single answer that fits every environment equally is rare. This article covers facts from three classics (CAP, PACELC, Conway's Law) that show context dependence.

1. Where trade-offs live

Most software decisions are trade-offs. Faster response weakens consistency; stronger consistency reduces availability. Smaller PRs review faster, but it's harder to convey the intent of a large change in one breath.

"Best practice" is only an after-the-fact observation that something worked well in some context — there's no guarantee it transfers cleanly to another. Context includes team size, team distribution, domain, operational headcount, regulation, budget, and code lifespan.

2. CAP

A theorem first presented by Eric Brewer in 1998 and formalized in his PODC 2000 keynote. In 2002, Seth Gilbert and Nancy Lynch published a formal proof.

The proposition — a networked distributed data store cannot simultaneously guarantee all three of:

• Consistency — every read sees the most recent write or returns an error.
• Availability — every healthy node responds to requests (data freshness is separate).
• Partition tolerance — the system keeps working even when network messages are delayed or lost.

Real distributed systems where partitions can occur cannot give up P, so the saying goes that at partition time, one chooses between C and A.

Brewer himself corrected the oversimplification "pick two of three" in his 2012 article "CAP Twelve Years Later". Real systems satisfy both properties closely during normal (non-partition) operation, and only choose behavior at partition time.

Representative classification:

• CP — MongoDB (default settings), HBase, ZooKeeper.
• AP — Cassandra, CouchDB, DynamoDB (depending on configuration).

3. PACELC

Proposed by Daniel Abadi in his 2010 article "Problems with CAP" and the 2012 IEEE Computer paper "Consistency Tradeoffs in Modern Distributed Database System Design":

If Partition: choose A or C
Else (during normal operation): choose Latency or Consistency

This covers the trade-off CAP doesn't address (latency vs consistency) during normal operation. Strong-consistency replication tends to require additional round trips even during normal operation, increasing latency.

The PACELC view shows how "best practice" varies by environment. Even the same DB falls into different categories depending on its consistency level and replication topology.

4. Conway's Law

A line from Melvin Conway's 1968 paper "How Do Committees Invent?":

"Any organization that designs a system... will inevitably produce a design whose structure is a copy of the organization's communication structure."

The observation is that an organization's communication structure ends up mirrored in the system structure. The implication is that many system design decisions are in fact organizational decisions.

The Inverse Conway Maneuver (organized by Lewis & Fowler and others) is the deliberate application — when you want a particular system structure, change the team structure first to match. Team Topologies (Skelton & Pais, 2019) organizes this view into team operating patterns.

5. Decisions made with trade-off awareness

These self-questions help:

1. What does this decision give up? — every decision gains one thing and forgoes another.
2. Can the cost be borne in the current environment? — the same decision costs differently depending on team size and operational headcount.
3. Is it reversible? — be careful with one-way decisions, fast on two-way ones (Bezos's "one-way vs two-way doors" analogy).
4. Whose best practice is it? — Google's best practice often does not transfer to a 5-person team.

6. Other expressions

Phrases often used in place of "best practice":

• good default — a starting point absent other information.
• fit for purpose — suited to the goal.
• context-dependent — depends on context.

These expressions are more honest because they return decision responsibility to context evaluation.

7. Common pitfalls

Justifying a decision only with "X is best practice" hides the difference between the environment where X emerged and the current one.

Cases from large companies (Google, Netflix, Spotify) are solutions grown in their scale and culture. There are repeated reports that even within Spotify itself, the "Spotify model" was operated in modified form.

CAP and PACELC are technical trade-offs about distributed systems; not every system is distributed. Citing CAP for a single-node system is a misunderstanding.

When trade-off awareness becomes analysis paralysis that delays decisions — these self-questions are tools for clear decisions, not tools for endless comparison.

Closing thoughts

The phrase "best practice" itself can become a word that shifts responsibility away. Every decision has trade-offs, and the same decision costs differently depending on environment. CAP, PACELC, and Conway's Law are the three classics that demonstrate this most often. Writing down "why this place" leaves a place where the future self and colleagues can re-evaluate the decision.

Next

• progressive-refactor
• docs-for-agent-and-human

Wikipedia CAP theorem · Eric Brewer CAP Twelve Years Later · Daniel Abadi Consistency Tradeoffs (PDF) · Melvin Conway How Do Committees Invent? · Team Topologies official site · Martin Fowler Inverse Conway Maneuver · Will Larson Engineer's Guide to Best Practices for reference.