Sam Newman

Tags

Sam Newman

Distributed systems consultant, author, and speaker; most widely known for formalizing the microservices architectural style through "Building Microservices" and for naming and documenting the BFF-Pattern (Backend For Frontend).

Core Idea

Sam Newman is not a framework creator or open-source project maintainer — his contribution is conceptual: he observes patterns emerging across the industry from his consulting work, names them clearly, and documents them rigorously. This makes diffuse practices legible and transferable. The BFF-Pattern is the clearest example: the practice existed at SoundCloud and Netflix before Newman named it, but without a name and a clear definition, teams could not easily discuss, adopt, or critique it.

Key Contributions

Backend For Frontend (BFF) Pattern

Newman formalized and named the BFF pattern, publishing the definitive write-up at samnewman.io. The pattern emerged from his consulting work observing how teams at SoundCloud and elsewhere were independently arriving at the same solution: separate server-side backends for each client type. By giving it a name and a canonical definition, Newman made it adoptable by teams who were not at SoundCloud.

Key claims Newman makes about BFF:

  • BFF is fundamentally an organizational pattern, not just a technical one — the benefit is team autonomy, not just technical separation
  • A BFF must be owned by the same team that owns the frontend it serves — otherwise you recreate the coordination bottleneck
  • If a BFF serves more than one distinct client type, it is no longer a BFF; it is a generic API

Building Microservices (O'Reilly)

First edition published 2015; second edition 2021 (significantly updated to cover service mesh, GraphQL, and evolved BFF practices). This book is the most widely cited reference for microservices architecture, covering:

  • Service decomposition strategies (by domain, by team, by volatility)
  • Inter-service communication (REST, gRPC, messaging)
  • Deployment and infrastructure (containers, Kubernetes, service mesh)
  • Testing strategies (consumer-driven contract testing, end-to-end testing trade-offs)
  • UI patterns including BFF

Monolith to Microservices (O'Reilly, 2019)

Practical guidance on migrating existing monolithic systems to microservices incrementally. Introduces patterns like the Strangler Fig Pattern for safe incremental migration.

How It Works (Consulting Model)

Newman's influence operates through consulting engagements with technology companies, conference talks (QCon, GOTO, microXchm), and his writing (books, blog). His pattern documentation follows a consistent structure: problem statement → forces at play → solution → trade-offs → related patterns. This format makes his writing directly applicable.

Relationship to BFF Architecture in Spring Boot

When implementing BFF with Spring Boot, Newman's conceptual framework provides:

  1. The argument for why BFF is the right architecture (team autonomy, not just technical separation)
  2. The boundary definition (one BFF per client type, owned by the client team)
  3. The relationship to the API-Gateway-Pattern (BFF sits behind a gateway; gateway handles infrastructure; BFF handles client concerns)
  4. The caution against "mega BFF" (a BFF that tries to serve multiple client types is an anti-pattern)

Key Positions and Opinions

  • Against "smart gateways": Newman advocates for putting business logic in services and aggregation in BFFs, not in the API Gateway. Gateways should be "dumb pipes" for infrastructure concerns.
  • On team topology: His architectural recommendations align closely with Team Topologies thinking — architecture should enable team autonomy, not require coordination.
  • On GraphQL: Newman acknowledges GraphQL as a valid alternative to BFF for certain scenarios, particularly when you have many diverse consumers. He does not treat them as mutually exclusive.
  • On service mesh: In the 2nd edition of "Building Microservices," Newman integrates service mesh as the appropriate layer for mTLS and observability between services, clarifying it as complementary to (not a replacement for) the BFF-Pattern and API-Gateway-Pattern.

Common Misconceptions

  • "Newman invented BFF" — He named and formalized it. SoundCloud engineers (including Phil Calçado) independently discovered the pattern in practice. Netflix arrived at similar conclusions separately.
  • "Newman's recommendations are prescriptive rules" — He consistently frames patterns with trade-offs. The BFF write-up explicitly lists when NOT to use BFF.

Why It Matters

Understanding that BFF comes from Newman's empirical consulting observation — not from theoretical first principles — explains why it is so pragmatic. It is a description of what worked at scale organizations. This practical provenance is important context when evaluating whether to adopt BFF: it has been validated at SoundCloud, Netflix, and many large engineering organizations, not just proposed in academia.

ConceptRelationship
BFF-PatternNewman named and formalized this pattern
API-Gateway-PatternNewman clarified the BFF vs API Gateway distinction
Service-MeshCovered in "Building Microservices" 2nd ed. as infrastructure complement to BFF

Sources

  • Sam Newman, "Pattern: Backends For Frontends" — samnewman.io (primary source for BFF pattern)
  • Sam Newman, "Building Microservices" 2nd ed. (O'Reilly, 2021)
  • Sam Newman, "Monolith to Microservices" (O'Reilly, 2019)
  • Phil Calçado, "Building Products at SoundCloud" — corroborates BFF origin story from SoundCloud side
  • P1-BFF-Foundations — FOUND-01 covers Newman's role in formalizing BFF; sources cite his work throughout
  • BFF-Pattern — Newman is the primary reference for the BFF pattern definition
  • API-Gateway-Pattern — Newman clarified the BFF vs API Gateway distinction

Linked mentions