Entering an ecosystem of forty microservices
The service count says little. What actually matters when you enter a system of this size?
Forty microservices can be an architecture or forty different ways of doing the same thing. The difference lies in the shared libraries, the conventions and the way services talk. A well-grown ecosystem has internal packages for HTTP, logging, cache, authentication and domain, published on a private registry and used by everyone. That is where the real architecture is read, before the code of any single service.
How you enter
The first weeks are for reading: the shared packages, the event flow between services, the database schema, the pipelines and QA environments. Then you take on a real piece, inside the team's workflow: same conventions, same ticketing tool, same weekly releases. The measure of how far in you are is simple: after eight weeks, on how many repositories you are the first contributor.
The rule for the first refactor is firm: input and output do not change by a comma, only how it is built inside changes. A four-thousand-line service in one file becomes an object structure by category, with typed containers in place of arrays passed from hand to hand, and every step preserves the observable behaviour.
Parity is measured on real data
When the new catalogue must return the same prices as the old one, parity is measured by comparing outputs for real users and markets. That is how you discover that for the same user the old system returned eleven promotions and the new one fourteen, because of a difference in how groups were collapsed and in routing by province. Found before release, it is a bug. Found after, it is a customer paying a different amount.
Describe the system. We'll tell you what we see.
Ten minutes, one question at a time. At the end, our honest read of the case. It's the filter, before the call.