R.I.P. The Story of How the System I Built Crossed the Rainbow Bridge 🪦🍂

Kakao Bank's Banking Server Team launched the Oslo Project to prevent failures in the core banking system from propagating across the entire service. At the time, they built a fully independent system separate from the core banking system in order to overcome the limitations of the monolithic architecture.

Oslo replicated core banking data in real time and acted as a Shield, independently handling the 'load full account list' function. Through this, it distributed about 10.22% of core banking traffic, and achieved an approximately 82% improvement in API processing time, from 400ms to 70ms.

However, this system—once called a Best Practice and having delivered successful results—reached EOS (End Of Service) just 3 years after its introduction. This was not a technical failure, but a strategic decision made in light of the changing environment, the organization's resources, and the pursuit of a better architecture.

This process leaves behind three key insights.

• Yesterday's right answer isn't necessarily today's right answer: the technically optimal solution changes depending on circumstances.
• The best decision-making is situational: it's important to make the best choice within the organization's capabilities and resources.
• Reversibility must be secured: a system should have the flexibility to pivot in a new direction or revert to a previous state at any time.