Microservices should form a polytree

Polytree vs. DAG as a Design Constraint

• Many commenters agree avoiding directed cycles is important, but argue a general DAG is sufficient; requiring a polytree (no undirected cycles, unique path to each node) is seen as over‑constraining.
• Critics say the article doesn’t convincingly explain why undirected cycles are harmful beyond standard diamond‑dependency issues (e.g., inconsistent views of upstream state).
• Some view the “polytree” angle as graph‑theory overreach: interesting intellectually, but not backed by empirical evidence or realistic examples.

Shared Infrastructure and Cross‑Cutting Concerns

• The strongest pushback targets the idea that no service should be depended on by multiple parents.
• Common shared services—authN/authZ, logging, metrics, configuration, feature flags, storage, image hosting, notifications, DNS—naturally break the polytree property.
• Proposals to work around this include:
  • Doing auth at a gateway and passing claims downstream (JWT, enriched headers).
  • Treating logging and metrics as “fire‑and‑forget” to a bus, not hard dependencies.
• Many argue duplicating such services per consumer just to preserve a polytree is unrealistic and wasteful.

Failure Isolation, Service Types, and Siloing

• Several comments pivot to the real value of microservices: isolating failure modes and enabling independent scaling, rather than obeying a specific graph shape.
• One concrete pattern: classify services into infrastructure, domain/business, and orchestration, with allowed call directions (orchestration → domain → infra) to avoid cycles and clarify responsibilities.
• Others describe success stories where auth was made stateless (JWT) so an auth outage didn’t take down other APIs.

Enforceability and Evolution Over Time

• Multiple people doubt such topological purity can be maintained as business needs evolve (e.g., GDPR‑style “delete all user data” flows, cross‑cutting features).
• Even in DAGs, accidental cycles arise via helpers and libraries (services effectively calling themselves).
• IAM/network policy can restrict who may call whom, but doesn’t solve the design‑level tension between purity and changing requirements.

Analogies, Alternatives, and Scope of “Micro”

• The “tree” idea is likened to Erlang/Elixir supervision trees, actor hierarchies, and general acyclic dependency rules in monoliths and OO inheritance.
• Some stress that microservices should be relatively coarse, business‑domain‑aligned units, not tiny functions; edges (service contracts) are expensive and should be minimized.
• Overall sentiment: acyclic, one‑way dependencies and clear boundaries are widely supported; strict polytree topology is seen as occasionally useful as a mental model but too rigid for many real systems.