Scaling a Chinese Kindergarten Platform: From Monolith to Microservices

Birth Phase – Architecture Selection V1.0

During the startup, limited resources led to choosing a simple LNMP stack (Linux, Nginx, MySQL, PHP). Three ECS servers were deployed: Nginx+application, RDS database, and Memcached. This monolithic architecture was easy to maintain and supported rapid iteration.

Simple monolithic structure with clear layers

Fast development for rapid product iteration

Low learning and operational cost

The LNMP stack supported growth for about a year and a half before limitations appeared.

Growth Phase – Architecture Refactor V2.0

In early 2015, the team expanded to three developers and rebuilt the system as a Java‑based distributed architecture. Motivations included database design issues, need for separate client apps, tangled API logic, single‑point database failures, and tightly coupled third‑party services.

The refactor was performed alongside ongoing development, resulting in a distributed deployment with system‑level splitting, service isolation via Hessian RPC, database master‑slave separation, introduction of MQ, and SLB load balancing.

Distributed deployment for easy scaling

System‑level splitting with independent databases

Initial service‑orientation using Hessian RPC

Physical DB isolation and master‑slave replication

Asynchronous processing via MQ

High‑availability Nginx load balancing with SLB

System and DB Splitting

Two phases: first split the monolith into independent subsystems while sharing a single DB; then separate each subsystem’s tables into distinct RDS instances with master‑slave setup.

Initial Serviceization

Used Hessian for RPC calls and extracted common services into independent components.

SLB Load Balancing

Moved from single‑point Nginx to multiple Nginx instances behind SLB, eliminating single‑point failures.

Explosion Phase – Microservice Architecture V3.0

From 2016 onward, rapid user growth and complex business logic required a full microservice architecture. Adopted Dubbo as the RPC framework, split business logic into independent services, each with its own database, and introduced service governance tools.

Service‑centric design

Loose coupling and independent deployment

High scalability and high availability

Key microservice examples include a high‑traffic class‑dynamic service and a user‑passport service, both achieving better performance, code reuse, and data consistency through DB sharding and isolation.

Microservice Governance

Implemented a version release system with automated deployment, gray releases, quick rollback, and audit workflow. Adopted Disconf for distributed configuration management and Elastic‑Job for task scheduling. Integrated Cat APM for full‑link tracing, customized Dubbo authorization, and built monitoring dashboards for success/failure rates, latency, and concurrency. Managed services via Dubbo’s console for routing, weight adjustment, degradation, and fault tolerance.

Future – Architecture Evolution V4.0

Planned improvements: Docker container deployment for elastic scaling, a unified API gateway for authentication, traffic control, and security, and multi‑IDC cross‑region deployment to achieve disaster recovery and latency reduction.

Conclusion

Architecture must evolve with business needs. Monolithic designs suit early rapid development, while distributed and microservice architectures provide scalability, maintainability, and high availability as the product matures, albeit with higher operational complexity.