Microservices are a tax your startup probably can't afford

Original Article ↗ Hacker News Discussion ↗

Microservices as Organizational Pattern, Not Startup Default

  • Many argue microservices primarily solve organizational problems: letting multiple long‑lived teams own independent domains and deploy on their own cadence.
  • For startups or orgs with <~5–10 engineers, this overhead is seen as pure tax: more repos, infra, coordination, and fragile local setups, with no real scaling or team benefit yet.
  • Several note that team boundaries are often unstable in startups; tying architecture to transient org charts backfires.

Costs, Failure Stories, and Overengineering

  • Numerous anecdotes: tiny user bases (hundreds or low tens of thousands of MAUs) running dozens of services or hundreds of Lambdas, burning years and millions, then collapsing or rewriting back to a monolith.
  • Common problems: complex deployments, hard local dev, slow onboarding, brittle inter-service contracts, and “distributed monoliths” with tightly coupled services and shared databases.
  • Nanoservices (one-table DB per service, or single-URL Lambdas) are widely mocked as pure overhead.

Alternatives: Monoliths, Modular Monoliths, and “Regular” Services

  • Strong support for starting with a monolith, sometimes split only into frontend/backend and a background job worker.
  • “Modular monoliths” with clear module boundaries, DI, actors, and tools like CODEOWNERS/ArchUnit are presented as giving many microservice benefits (interfaces, isolation) without network and ops tax.
  • Some advocate single codebase / multi-role binaries or monorepos with multiple deployable services.

When Microservices (or Separate Services) Do Make Sense

  • Repeated “good reasons” cited:
    • Very different resource/scale or availability requirements (GPU jobs, hot paths, queue pollers, control vs data plane).
    • Different tech stacks (e.g., Ruby app plus R or Python for data/ML).
    • Distinct security/compliance or data‑lifecycle needs (healthcare data, auth).
    • Large orgs (many teams) needing independent lifecycles and risk isolation.
  • Even then, advice is to avoid synchronous chains, noun-based services, and shared DBs; favor bounded contexts and async messaging.

Tooling, Testing, and Culture Requirements

  • Successful microservice setups are said to require: strong shared standards, dedicated platform/devops/tooling teams, robust CI/CD, observability, and often end‑to‑end tests.
  • Debate appears around “broken builds”, test guarantees, and static vs dynamic typing, but consensus is that without solid engineering discipline, microservices amplify problems.
  • Some note microservices force serious API and modularity design; monoliths often don’t get the same design rigor unless the engineering culture is strong.