Skip to content

CONCEPT Cited by 1 source

Service-oriented architecture (SOA)

Definition

Service-oriented architecture (SOA) is the design pattern of decomposing a system into small services, each dedicated to a specific well-encapsulated domain area (e.g. rider billing, driver payouts, fraud detection, analytics, city management). Each service can be written in its own language or framework and can have its own database — or lack one entirely. Inter-service communication is via network RPC, HTTP, or messaging.

As the standard intermediate step between a monolith and a fully-fleshed microservices fleet, SOA is essentially the term industry used ~2008–2015 for what is now routinely called "microservices" (the line is fuzzy; microservices is often framed as "SOA done with smaller grain and more automation").

Why orgs adopt it

  • Clear domain boundaries reduce the merge-conflict rate on a shared codebase.
  • Language/framework heterogeneity lets teams pick the right tool per domain.
  • Team scaling side-effect. As services become individually ownable, engineers can be separated into dedicated teams aligned to service boundaries — Conway's Law made deliberate.
  • Independent deploy cadence. Domain teams ship at their own pace without blocking others on monolith release trains.

Why orgs struggle

The exact same properties that make SOA attractive — service heterogeneity, autonomy, independent deploys — create operational complexity:

  • Without a shared service framework, service-level observability, tracing, and config are reinvented per team.
  • Without consistent RPC conventions (fault tolerance, rate limiting, circuit breaking), inter-service cascades become the new failure mode.
  • Without clear domain boundaries, ~N² service-to-service dependencies produce a distributed monolith — all the cost of services, none of the isolation.

Josh Clemm's framing in the 2024 Uber retrospective:

"While microservices can solve many problems, it also introduces significant operational complexity. You must only adopt microservices after understanding the tradeoffs and potentially build or leverage tools to counteract those tradeoffs. And if you don't consider the operational issues, you will simply create a distributed monolith." (Source: sources/2024-03-14-highscalability-brief-history-of-scaling-uber)

Canonical case studies

  • Uber 2013–2018. API monolith split into ~100 services in 2014; grew to thousands by 2018. To prevent distributed-monolith devolution, Uber built an entire in-house service platform — Clay (framework), TChannel + Hyperbahn (RPC + routing), Thrift (IDL), Flipr (feature flags), M3 (metrics), Nagios (alerting), Merckx→Jaeger (tracing). Even so, by 2018 Uber faced Project Ark — thousands of services, 12,000 repos, "5 or 6 systems doing 75% the same thing" — precisely the distributed-monolith failure mode the tooling was supposed to prevent.
Last updated · 517 distilled / 1,221 read