Case Study · Business Platform
22 microservices in a shared business system.
CRM, calculators, quotes, contracts, documents, knowledge base and reports in a financial advisory platform. Anonymised client work with senior full stack and DevOps responsibility.
The system question
How does the platform stay coherent without every part being tightly coupled?
Shared authentication and business concepts were needed, while each service had to remain independently developable.
Business capabilities
It is not the number of services, but the responsibility boundary that matters.
Engineering lessons
Microservices are not a goal, but an organisational and responsibility decision.
- 01
Data ownership
Every piece of business data has one owner; the other services ask for it, they do not write it.
- 02
Shared concepts
Shared authentication and business models create coherence, but must not turn into hidden coupling.
- 03
Cross-service flows
From quote to contract, one process runs across several services. It has to stay traceable.
- 04
The cost of operations
Twenty-two services carry release and operational overhead. The count alone is not a value.
Technology
The stack serves the decisions, not the other way round.
What we do not disclose
The client name and internal metrics stay private.
This was client work on the internal platform of a Hungarian financial and insurance advisory network. We do not publish the client name, user counts or internal business data, and we do not publish codebase-size figures either: those are not business outcomes. What we do state verifiably is the scope of responsibility and the architectural decisions. We are glad to discuss the rest in person, within the limits of confidentiality.
Next step
Is your system size already blocking change?
Platform Evolution is not automatic rewriting. We first map the responsibility and operational constraints.