為何過早採用微服務會拖垮初創醫療科技公司，以及替代方案

In modern software development, splitting applications into microservices has become the default architectural dogma. Many engineering teams assume that without ten isolated services orchestrated by Kubernetes and Kafka, an application is fundamentally unscalable.

In digital health and regulated software, this impulse is uniquely destructive.

Healthcare systems do not struggle because of raw HTTP throughput or web-scale traffic. They struggle because of strict data integrity guarantees, regulatory audit compliance, complex clinical workflows, and fast-evolving domain logic. Breaking an early-stage health product into distributed microservices before core domain boundaries stabilize introduces crushing operational complexity without solving any business problem.

Here is why premature distributed systems break healthtech architectures—and the pragmatic alternative engineering teams should adopt instead.

1. The Distributed Data Nightmare in Regulated Domains

In an e-commerce platform, eventual consistency is acceptable: an inventory counter or view count can lag by several hundred milliseconds without significant consequences.

In clinical systems, transactional consistency is non-negotiable. Consider a routine triage event:

1. A clinical encounter is registered.

2. Sepsis screening vital signs are recorded as clinical observations.

3. An automated clinical decision rule flags early organ dysfunction risk.

4. A critical task notification is dispatched to attending medical staff.

In a premature microservices system, these operations span four independent databases managed by separate services (Encounter-Service, Observation-Service, Rules-Engine, and Notification-Service).

Once business logic is distributed across networks, native ACID transactions disappear. Developers must orchestrate two-phase commits or complex distributed Saga patterns with compensating transactions. If a network partition occurs midway through execution, audit records desynchronize and alerts risk silent failure.

Instead of validating clinical workflows with users, engineers spend their working hours debugging distributed tracing, network timeouts, and idempotency keys.

2. Unstable Domain Boundaries Cause Continuous Distributed Refactoring

Microservices excel when domain boundaries are mature, well-understood, and structurally static (the classic "Bounded Context" in Domain-Driven Design).

In early-stage healthtech, domain models change continuously:

• Regulatory reporting mandates (such as FHIR profiles) evolve.

• Hospital intake workflows vary across enterprise clients.

• Billing rules and clinical coding requirements shift.

When domain boundaries shift within a monolith, refactoring is a safe, compiler-checked internal operation: developers rename modules, adjust domain entities, update the relational schema via an atomic migration, and deploy.

When domain boundaries shift across microservices, a simple entity alteration becomes a massive cross-team operational chore:

• Coordinated multi-database migrations.

• Versioning distributed REST/gRPC contracts while preserving backwards compatibility.

• Supporting parallel API versions across clients.

3. The Pragmatic Alternative: The Modular Monolith

Rejecting microservices does not imply creating tightly coupled, unmaintainable code. The most resilient pattern for early-stage and growth-phase health systems is the Modular Monolith.

healthtech_app/
├── core/                  # Shared database configuration, security, audit logging
├── patients/              # Bounded context: demographics, consent management
│   ├── domain/            # Pure entities, domain validation logic
│   ├── services/          # Application use-cases
│   └── api/               # Public REST endpoints
├── observations/          # Clinical vitals, laboratory tests, FHIR mappings
└── clinical_rules/        # Deterministic decision support and alerting

In a modular monolith:

1. Single Deployment & Unified Storage: The platform deploys as a cohesive application against an enterprise relational database (such as PostgreSQL). You maintain foreign keys, atomic transactions, and instantaneous rollbacks.

2. Encapsulated Boundaries: Modules interact exclusively through defined service interfaces or internal domain events, never through direct queries to internal module tables.

3. Turnkey Audit Compliance: Meeting HIPAA, GDPR, or LGPD access audit mandates is trivial when all entity lifecycle events pass through unified ORM middleware.

4. When Should You Actually Decompose a Service?

Microservices address human team communication bottlenecks in large engineering organizations, not software cleanliness. You should consider carving out an independent service only when:

• Asymmetric Compute Profiles: A single process demands specialized hardware (such as GPU instances for medical imaging inference or continuous ML model training) while web APIs run on cost-effective CPU clusters.

• Extreme Independent Ingestion: Telemetry streams (such as real-time IoT vital monitors) produce high-frequency write operations that would saturate the primary application connection pool.

• Team Scale Bottlenecks: The organization exceeds 30–40 developers, and deployment contention on a single codebase creates persistent organizational deadlocks.

Conclusion

Engineering maturity is not measured by how many distributed components run in a cloud environment; it is measured by delivering clinical value and reliable data integrity with the simplest sustainable architecture.

In digital health, where architectural failure impacts patient care, a well-structured modular monolith provides superior stability, velocity, and compliance safety.