Is Microservices a Silver Bullet? Lessons from Migrating a Monolithic System to Microservices

Microservices have become a buzzword since 2014, and the article begins by listing their typical characteristics: services as components, business‑oriented organization, strengthening endpoints while weakening pipelines, product‑centric thinking, independent deployment, single responsibility, decentralization, and DevOps‑aligned structures.

The author describes Company A's original architecture, which relied on a Tomcat cluster and a single Oracle database replicated via DataGuard. Although this setup handled a modest transaction volume, a sudden spike to 500 TPS caused timeouts and severe database pressure, revealing that simply adding more servers could not solve the bottleneck.

Consequently, the team decided to adopt microservices. The core principles of data decentralization were highlighted: each microservice owns its own persistent database, can only access its own data store, cross‑service transactions must be performed through service calls, and overall coupling is reduced.

After refactoring, the system was re‑architected into a set of independent services, as illustrated by the accompanying diagram.

The migration introduced several operational challenges:

Manual WAR‑based deployments by a small ops team led to frequent errors and overnight releases.

Database sharding created difficulties for reporting and analytics, requiring massive effort to aggregate data across multiple databases.

Achieving true active‑active database replication for Oracle proved problematic; solutions like OGG, LogMiner, and DataGuard each had drawbacks, prompting the team to develop a custom approach.

Adopting frameworks such as Dubbo or Spring Cloud did not eliminate the need for additional infrastructure like distributed tracing, configuration management, scheduling, idempotency, rate limiting, and cache isolation.

Specific pitfalls with Spring Cloud were also discussed, including IP registration issues in Eureka, intermittent health‑check failures causing service deregistration, and performance problems caused by improper use of Feign.

In the final review, the author argues that while microservices offer many benefits, they should not be adopted blindly. Proper research, a comprehensive migration plan, and gradual evolution are essential, especially for fast‑growing startups with limited resources.