Architecture in a Large Fintech: Yesterday, Today, Tomorrow

Initially, the company built products on commercial systems, including Oracle Siebel. This reduced upfront investment and provided access to vendor documentation, support, and updates. Specialists combining business analysis and project management designed the processes. Their job was to connect existing systems in ways that quickly supported useful customer journeys.

As customer numbers and product complexity increased, limitations became more significant: licensing costs, vendor dependence, difficult integrations, and restricted customization. The company began replacing some packages with its own software. Designing and maintaining these systems proved harder than integrating ready-made products. Some replacements were themselves superseded while the original package remained operational, illustrating why migration is rarely a single clean swap.

By 2020, separate infrastructure efforts across teams had become an economic problem. The author cites historical figures from a colleague: development teams had grown eightfold, while roughly a quarter of engineers worked on delivery tooling, infrastructure support, and application reliability. A diverse technology landscape also hindered reuse. These figures describe one stage of the company, not a general industry benchmark.

The response was Spirit, an internal developer platform. Its principles included a repeatable and transparent code lifecycle, quality management, shared internal development, and a focus on outcomes. The article also describes a shift toward engineers' experience. A platform's value depends on which real tasks it makes easier, beyond the existence of common tools or a central platform team.

The next stage combined the Prometheus technology replacement program with the 100M program to prepare high-load systems for growth. Demand increased through more customers, more products per customer, and more frequent use. Applications were encouraged to adopt platform services while those services improved scalability, security, and resource efficiency. Changes had to proceed gradually within systems already serving users.

Renaming an existing system a platform does not make it reusable. Consumers need defined scenarios, architectural characteristics, development plans, contribution rules, and self-service access. The author advocates making architectural decisions at the lowest appropriate level and developing engineers' design skills, including the Staff+ track. The closing priorities are investment in data centers, the internal platform, and decentralized architectural governance. These are the stated direction at the time of publication.