Preserve logical boundaries even when physical deployment is simple
- A monolith can preserve clean architecture if boundaries are typed.
- Microservices can still be bad architecture if every service leaks authority, prompt text, and provider assumptions.
- Physical separation is not a substitute for explicit contracts.
Start with the authority, state, evidence, and failure boundaries. Choose process and network placement after those contracts are explicit. Clean Architecture’s dependency direction applies whether components run in one process or across many hosts. Source: Architecture guidance
Deployment trade-off table
| Deployment Shape | Best For | Risks | Required MIR Controls |
|---|---|---|---|
| Local | Privacy, user-controlled tools, small teams | Limited hardware, local secrets risk | Local evidence, explicit egress, scoped credentials |
| Modular Monolith | Early product, low-latency internal calls | Boundary erosion | Strict ports and adapters, internal modules, tests |
| Microservices | Independent scaling and ownership | Latency, distributed failure, operational complexity | Tracing, circuit breakers, idempotency, event contracts |
| Serverless | Spiky lightweight tasks | Cold starts, stateless limits, weak GPU fit | Durable state, external evidence, timeout-aware design |
| Cloud-managed | Enterprise operations and managed scaling | Lock-in and opaque control boundaries | Exportable evidence, provider-neutral contracts |
| Edge | Latency-sensitive or offline-adjacent workflows | Sync and update complexity | Local policy, eventual evidence sync |
| Federated | Cross-organization work exchange | Identity, trust, protocol, evidence compatibility | Bounded delegation, signed evidence, explicit contracts |
Hybrid is often a composition rather than a separate shape: local policy and tools, remote inference, managed queues, and centrally retained evidence can coexist. The boundaries must state which system is authoritative when connectivity or synchronization fails.
Latency versus purity
Remote-service purity can add network, serialization, authentication, queueing, and operational overhead. In-process placement can reduce those costs but increases failure-domain coupling and may constrain scaling. Neither choice is automatically correct.
Measure real end-to-end workflow latency, tail behavior, recovery time, and task completion—not only model inference time. Keep logical contracts stable so placement can change after measurement. Cloud design guidance treats latency, reliability, messaging, and distributed consistency as explicit trade-offs rather than incidental implementation detail. Source: Cloud design patterns
Decision checklist
- What data must stay local?
- Which actions require human approval?
- What is the maximum workflow latency?
- What must be recoverable?
- Which side effects are irreversible?
- Which model routes are allowed?
- What evidence must be retained?
- What must be exportable?
- Which failures need safe fallback?
- Which teams own each boundary?
Explicit contracts, locality rules, latency budgets, circuit breaking, idempotency, and evidence export are production practices. Federated MIR delegation and cross-organization evidence compatibility remain emerging practice.
Source record
References
Microsoft. Microsoft Learn. Published Current documentation; last reviewed 2026-06-23 UTC. Official architecture guidance.
- Cloud Design Patterns Primary source
Microsoft. Azure Architecture Center. Published Current documentation; last reviewed 2026-06-23 UTC. Official architecture guidance.
National Institute of Standards and Technology. NIST. Published 2023-01-26; last reviewed 2026-06-20 UTC. Government framework.