Microservice Architecture: Evaluation, Adoption Timing, and Implementation Considerations

1. Monolithic Architecture

Monolithic applications are quick to develop and validate ideas, requiring relatively low resource investment.

Fast development and proof‑of‑concept.

Cost‑effective in terms of manpower and infrastructure.

However, as business complexity grows, monoliths suffer from reduced flexibility, IDE overload, scaling limits, deployment conflicts, and poor extensibility.

For early‑stage projects with unclear requirements and limited traffic, a monolith is the most efficient and economical choice.

2. Microservice Architecture

Advantages

Microservices support large‑scale, high‑concurrency workloads, multi‑region deployment, and unlimited server scaling, making them the preferred choice for many internet companies.

Costs

High technical threshold: requires service registry, discovery, authentication, monitoring, tracing, governance, containers, CI/CD, DevOps, etc.

Increased complexity: service granularity, inter‑service communication, and debugging become more challenging.

Organizational shift: changes development culture and team structure.

Higher upfront investment: infrastructure and skill development.

Typical Layered Structure

Layer 1 – Client: all devices that can connect to the network (mobile apps, web browsers, IoT devices, etc.).

Layer 2 – API Gateway: handles service registration, discovery, authentication, single sign‑on, circuit breaking, rate limiting, etc.

Layer 3 – Service Cluster: business services (user, order, etc.) and shared services (metadata, messaging, etc.). Example addresses: user.jackyfei.com , order.jackyfei.com , base.jackyfei.com , msg.jackyfei.com .

Layer 4 – Event Bus: decouples services via lightweight messaging (often RabbitMQ).

3. When to Adopt Microservices?

Expert Opinions

Yang Bo (former eBay architect) advises that startups should start with monoliths because microservices demand significant infrastructure investment and expertise; only when the product is validated and the team grows (around 100 people) does microservice adoption become worthwhile.

Hu Zhongxiang (Weibo microservice expert) notes that once a monolith has more than ten developers, productivity drops and the risk of cross‑module failures rises, indicating the need for service decomposition.

Key Decision Factors

Business complexity: high‑traffic, multi‑domain systems benefit from microservices.

Team size: larger teams (≈100) can justify the overhead.

4. Evaluation Criteria for Microservice Adoption

Adoption Path

Two main approaches:

Partner with an external architecture consultancy for demos and training.

Hire experienced engineers to build the platform internally.

Talent Reserve

Separate research‑oriented staff (core component R&D) from application‑oriented staff (implementation).

Technical Stack

Essential knowledge includes domain‑driven design, continuous delivery, distributed systems fundamentals, load balancing, CAP theorem, caching, DevOps, and containerization.

Team Size Assessment

Typical recommendation: one senior architect plus 3‑4 senior developers handling 2‑3 core services each; exact numbers depend on business scope.

5. Risks of Migrating to Microservices

Wide‑range rewrite: architectural changes affect many codebases.

High complexity: steep learning curve for numerous components.

Personnel requirements: backend developers must master microservice principles and related tooling.

Collaboration model: external partners increase handover time and require deep business understanding.

6. Service Decomposition Strategies

Vertical Splitting

Based on business domains; tightly related functions become a single service, while independent functions are split into separate services.

Horizontal Splitting

Based on shared, independent capabilities (e.g., metadata service, messaging service) that are used by multiple business services.

7. SOA vs. Microservices

SOA focuses on centralized integration, while microservices emphasize decentralized management, code reuse, and automation.

8. Conclusion

Adopt microservices only after careful evaluation of business complexity and team scale, adhering to the principles of simplicity, suitability, and evolution; otherwise, the “distributed systems first law”—"avoid distributed systems if possible"—still holds.