Let’s talk about architecture in BigTech, technology selection and accepted “rules”.
We will touch on the topic of freedom in adopting architectural solutions for the Product and Core teams.
We’ll get into Fintech solutions created as an important component of global SaaS: microservices, APIs and tags, Event Sourcing, Feature Toggles, SDLC, CI/CD, DevOps, monitoring, analytics, etc.

Global companies have long used microservices. For example, the monolithic applications of Amazon, Coca-Cola, and Netflix at some point evolved into larger infrastructures. Brands have benefited from this decision and attracted even more audiences. But trending doesn’t mean monoliths are yesterday’s day. My team and I are not used to blindly chasing new trends. We always analyze when one or another option is effective and how it is safer to switch to it.

Our fintech project was built on a monolithic approach. This approach resembles a Rubik’s cube: if you take one piece out of it and assemble a new form or add other components, the cube will no longer work fully. Each element forms a single functionality. If any part is missing, broken or standing out of place, the colored box will not add up.

Why did you choose the monolith? First, it allows you to launch the project faster in a startup. When you have to present MVP in a month, but you have no specific requirements or product specifications, Monolith is the only savior. Its flexibility is manifested in the variety of tools that can be integrated to simplify development. In addition, changes or updates can be deployed at once rather than individually. Second, monolith is easy and fast to scale at the start. For our team, the benefits were clear.

More specialists, including newcomers, can join development on monolith. It is simple and straightforward to use. In such an application, all components are interconnected and interdependent. It will be much easier for any novice to understand the code and logic implemented in monolith than in microservices.