Banksalad's Three-Year Journey Decomposing a Legacy Monolith into 15 Microservices, and Its Shadowing Strategy

Limits of the Monolith and the Decision to Decompose

For rapid early growth, Banksalad adopted a flexible type system based on Python and MongoDB, but over time this degenerated into a massive monolithic server. As the complexity of business logic surged to the point where guaranteeing correct behavior became difficult, the company adopted a decomposition strategy: removing the legacy service and breaking it down into services with lower complexity.

Applying Conway's Law and the 15-Microservice Structure

Drawing on Conway's Law—the idea that an organization's communication structure mirrors its software structure—Banksalad redesigned its services to align with its 'squad' system. The result was a structure composed of 15 microservices covering pensions, bank accounts, cards, investments, and more. During this process, the team focused on reducing complexity by clearly defining 'Non-goals' to reduce uncertainty and by not fixing errors in existing API specifications.

Verification and Stability via Shadowing

The key verification method for replacing legacy services was shadowing. Identical requests were sent to both the existing service and the new service, their responses were compared for consistency, and diffs were analyzed using statsd and Kibana. This approach allowed the team to proactively identify potential errors that would have been difficult to catch through manual staffing alone, such as decimal-point handling discrepancies and timezone bugs. Stability was verified by gradually increasing the traffic ratio starting from 1%, and a Chronograf dashboard was used to track project progress and detect failures in real time.

Organizational Culture and Project Outcomes

Throughout the project, the team maintained close communication through daily standup meetings, or every 2 hours when necessary. They also built a server template based on Go and gRPC, reducing boilerplate coding time and boosting productivity. After roughly 3 years, the legacy service decomposition was completed, and development speed afterward became fast enough that numerous server-wide feature improvements could be made within a month.