A developer-deployment platform must run builds, schedule long-lived services, stream logs and provision databases. Which architectural style fits, and what is the most common mistake in choosing?

The style that fits

The dominant decomposition is not "monolith versus microservices" — it is control plane versus data plane, which is a different axis entirely and the one that actually matters here.

• Control plane: the API, desired-state store, scheduler, build orchestrator, billing. Request rates are modest, correctness matters enormously, and a few seconds of latency is acceptable.
• Data plane: the running containers, the proxy handling customer traffic, log shipping. Request rates are orders of magnitude higher, latency matters, and it must keep working when the control plane is down.

Why the split is the whole design

The property you are buying is static stability: customer applications keep serving traffic during a control-plane outage. If the request path consults the control plane — for routing, for auth, for a limit check — then a control-plane deploy becomes a customer-visible outage, and the platform's own reliability is capped by the reliability of its least-important administrative endpoint.

That requirement dictates concrete things: routing configuration is pushed to the proxy and cached locally, the proxy holds last-known-good state, and the data plane degrades to "serve the old config" rather than "fail".

The common mistake

Choosing a style by team structure or fashion rather than by failure domain. A platform team that splits by nouns — "build service, log service, database service, user service" — ends up with the control plane and data plane interleaved across all of them, which is the arrangement in which every outage is total. The boundary that matters is the one that determines what stays up when something else falls over.

The secondary mistake is treating builds as ordinary control-plane work. Builds are bursty, expensive, untrusted and long-running — four properties that share nothing with the API — and they belong in their own pool with their own queue and their own capacity policy.