Microservices: Beyond Splitting - Decoupling, Governance & Conway's Law

01. Introduction

Microservices architecture is not a silver bullet; it is an architectural philosophy and an organizational cost. Many teams split monoliths only to face worse performance, harder operations, and untraceable failures. This article moves from tactical implementation to strategic thinking.

02. Essence of Microservices: Decoupling, Not Splitting

The core of microservices is decoupling by business boundaries to isolate change scope. Monoliths suffer from high coupling — changing one line risks unknown impacts. Microservices achieve decoupling through three dimensions: service boundaries, independent deployment, and independent data sources. However, decoupling is not free; flexibility demands accepting all distributed system complexities.

03. Service Decomposition: The Underestimated Challenge

The difficulty lies in boundary identification, not technology. Two mainstream paths exist:

By business capability (e.g., User, Order, Product, Inventory services). Pros: aligns with business intuition. Risk: easily creates a distributed monolith where changing Order still requires changing Inventory.

By DDD bounded contexts . More advanced, requires domain modeling skills, higher barrier but yields stable boundaries.

Practical advice: do not split too finely initially. If a business operation frequently requires cross-service calls, the boundary is likely wrong. Remember: a service is a business concept, not a technical one.

04. Microservices Governance: Where 90% of Teams Fail

4.1 Service Discovery

Client-side discovery (e.g., Eureka) vs. server-side discovery (e.g., Consul + load balancer). Production environments should prefer server-side discovery; client-side adds too much weight.

4.2 Configuration Management

Never hard-code configuration. Use a configuration center (Nacos, Apollo, Consul Config) with dynamic refresh support — no restarts.

4.3 Observability — The Lifeline of Microservices

Three indispensable pillars:

Distributed tracing (SkyWalking, Jaeger, Zipkin). Without it, debugging is like finding a needle in a haystack. 100% sampling is unrealistic in production, but critical interfaces must be fully sampled.

Metrics monitoring — Prometheus + Grafana is standard. Track the four golden signals: latency, traffic, errors, saturation.

Log aggregation — ELK or Loki. Crucial: include traceId to correlate logs with traces.

Without these three, your microservices are a black box.

4.4 Traffic Governance

Circuit breaking (Hystrix, Resilience4j, Sentinel)

Rate limiting (token bucket, leaky bucket)

Retries (mind idempotency)

Timeouts (avoid defaults)

A hard lesson: circuit breaking is not to prevent system crashes but to prevent failure propagation . Upstream circuit breaking protects downstream services.

05. Distributed Transactions: Accept That You Don't Need Strong Consistency

This is the most over-engineered area. Options include 2PC, TCC, Saga, local message tables. The truth: most business scenarios only need eventual consistency.

Selection principles:

Ultra-low strong consistency needs (e.g., financial core ledger) → TCC or 2PC, at performance cost.

General business → Local message table + message queue (RocketMQ/RabbitMQ) for reliable events.

Long-running processes → Saga pattern, requiring compensation design.

Practical tip: first ask if the scenario truly needs distributed transactions. Can reasonable decomposition or business process refactoring avoid them?

06. Data Governance: Each Service Owns Its Database, Then What?

After splitting services, databases split too. Challenges: cross-service joins and queries.

Anti-pattern : shared library or shared read/write database — reintroduces coupling.

Correct approaches :

CQRS (Command Query Responsibility Segregation): writes go through microservices, reads via materialized views or heterogeneous data sync.

API composition : application layer aggregates data from multiple services (simple scenarios).

Event-driven : sync data to query stores via events (complex scenarios).

Data consistency is ultimately achieved through events, not distributed transactions.

07. API Design: Your API Is Leaking Implementation Details

Inter-service communication via APIs determines system evolvability.

Good API traits :

Business-scenario oriented, not internal table structure.

Versioned from day one ( /v1/, /v2/).

Backward compatible (new fields don't break old callers).

Idempotency designed in (especially write operations).

Don'ts :

Expose database IDs (use business unique identifiers).

Leak internal error stack traces in APIs.

Merge multiple service APIs into a God API .

Contract testing (Pact, Spring Cloud Contract) makes service integration more reliable.

08. Infrastructure: Kubernetes Is the Starting Point, Not the Destination

Kubernetes is the de facto standard for microservice infrastructure but only solves deployment scheduling, not service governance. That's where Service Mesh (Istio, Linkerd) fits — pushing governance capabilities into the infrastructure layer.

Should you adopt Service Mesh?

Services < 30 → unnecessary, adds complexity.

Services > 100 → strongly recommended; governance cost already exceeds Mesh learning curve.

Reality: most companies' microservice scale is well served by Spring Cloud stack + Kubernetes.

09. Organizational Architecture: Conway's Law Is Speaking

System architecture mirrors the communication structure of the organization that built it. Teams split by function (frontend, backend, DBA) cannot produce good microservices.

Correct approach : form cross-functional teams by business line (including frontend, backend, ops, DBA). One team owns one or more cohesive services for the full lifecycle — requirements, development, test, deploy, operate, retire. This is the Inverse Conway Maneuver : design the desired architecture first, then reshape the organization to match.

10. When Not to Use Microservices

Think twice in these situations:

Team size < 10: monolith is more efficient; governance overhead is unsustainable.

Simple business logic, low change frequency: don't overdesign for trendiness.

Extreme latency sensitivity: distributed call network overhead is unavoidable.

No mature ops capability: CI/CD, containerization, monitoring/alerting are all mandatory.

Pragmatic advice: start with a modular monolith . Extract a service only when a module genuinely needs independent scaling, independent deployment, or a heterogeneous tech stack.

11. Future of Microservices: Two Directions to Watch

Serverless + Microservices : FaaS enables finer granularity, but cold starts and state management remain unsolved.

eBPF + Observability : eBPF enables kernel-level observability; future may achieve full tracing without application-level instrumentation.

Conclusion

Microservices is a first bitter, then sweet path: high upfront investment, difficult mid-term governance, clear long-term benefits — if done right. If you're in pain, the cause is almost certainly one of: unclear boundaries, incomplete governance, or organizational mismatch. Good architecture evolves; it is not designed upfront. This article skips framework tutorials (documentation covers those) and focuses on real pitfalls and real solutions. Save it for your next microservice design review.