Many Services
When service count grows, orchestration correctness is usually fine; developer feedback loop speed is the real constraint.
Typical pressure points
- long startup chains from dense
dependsOn - readiness probes on too many non-critical services
- high log throughput making incident analysis noisy
- frequent full-stack restarts for single-service changes
Mitigations
- Keep dependencies strict and minimal.
- Avoid serializing independent services into deep chains.
- Use targeted runtime commands (
restart_service) instead of full restarts. - Set sensible
logView.maxEntriesdefaults for noisy services. - Split optional subsystems into separate configs when they are not needed every day.
Signal that you outgrew one stack
- startup time becomes the main cost of each edit cycle
- one team's actions frequently destabilize another team's flow
- local machine thermal throttling is common during normal iteration
When these signals persist, split stacks intentionally instead of fighting one giant config.
See Waves and When to Split Stacks.