A guide to hiring a microservices developer
A microservices system is a product built from many small services, each doing one job and each able to be built, released and scaled on its own. A microservices developer designs those services, decides where the lines between them go and makes sure they work well together. The role is not only about writing code. It is about boundaries, communication, data and keeping a larger number of moving parts understandable. If your system is hard to change, or you want teams to release without waiting for each other, this role is worth a look.
What a microservices developer actually owns
The job covers the design of the whole system and the parts inside it. They choose how to split a product, build services with clear contracts and decide how services call each other. They own the way services are packaged and released, and the logs, traces and metrics that show how the system behaves. They also plan for failure, because with many services something is always slow or down somewhere. Your back end developers often work with them on the code inside each service.
When microservices make sense
Microservices solve organisational and scaling problems. They help when several teams need to release on their own, when one part of the product needs far more capacity than the rest or when a single codebase has become too tangled to change safely. They also give you a choice of language and data store for each service. These gains come with a cost, which is more infrastructure, more network calls and harder debugging. A good microservices developer weighs that cost against the benefit for your team.
When they do not
For a small team and a young product, microservices often slow you down. You pay for deployment, monitoring and network failures before you get any of the benefit. A well organised monolith, or a modular monolith with clear internal boundaries, is faster to build and simpler to run. A candidate who tells you this honestly is a good sign. A candidate who recommends microservices for every case is a warning. Splitting later is possible, and is easier when the code already has tidy modules.
Service boundaries
The hardest decision is where to cut. A useful rule is to split around business areas, such as billing, orders or accounts, and not around technical layers like a database service or a validation service. Each service should own one job and its data, and a change to a feature should touch as few services as possible. If two services always change together, the line is probably in the wrong place. Boundaries are easier to move early than late, so it is worth taking time to get a first version right.
REST, gRPC and messaging
Services talk in two main ways. Direct calls, such as REST or gRPC, are simple and give an answer right away, but they tie the caller to the speed and health of the other service. Messages and events, sent through a broker such as RabbitMQ or Kafka, let services work without waiting for each other and absorb spikes in traffic. They bring new problems, such as messages that arrive twice or out of order. A developer should know both styles and when to use each. For the public face of your system, see our API developers.
Data per service
In a classic microservices design, each service owns its data, and other services ask for it through an API or an event. Sharing one database between services is easier at first, but it ties them together and makes changes risky. The price of separate data is that a task spanning several services can no longer use one database transaction. Developers use patterns such as sagas, where each step can be undone, and they plan for data that is briefly out of date. Ask each candidate how they handled this in practice.
Containers and Kubernetes
Containers package a service with everything it needs to run, so it behaves the same on a laptop and on a server. Docker is a common tool for building them. Kubernetes is an open source system that runs many containers across several machines, restarts failed ones and rolls out new versions step by step. They are powerful, and they take skill to run well. Learn more from our Docker developers and our Kubernetes developers, or bring in a DevOps engineer for the pipeline around them.
Observability
With one application, a bug leaves a trail in one log. With many services, a single user request may pass through many of them. Observability is the set of tools that lets you follow it. Logs record events, metrics show trends such as error rates and response times, and traces follow one request from service to service. OpenTelemetry, Prometheus, Grafana and Jaeger are open source tools often used for this. Ask a candidate how they would find the slow service in a chain, and what they would alert on.
Moving from a monolith
A full rewrite is risky and slow. A safer path is to split one piece at a time. Choose a part with clear edges and a real need, such as a busy feature or one that changes often. Build it as a service, send a small share of traffic to it and compare the results. When it is proven, move all the traffic and remove the old code. Then repeat. You can stop at any point, and the product keeps working throughout. A CI/CD developer can help make each release smooth.
Languages and frameworks
Microservices can be written in almost any language. Go is popular for small, fast services, as you can see from our Golang developers, and Node.js suits services that handle many connections, which our Node.js developers know well. Python, Java and C# are common too. A team does not need a different language for every service. Using one or two keeps hiring and support simple, and the freedom to choose is best kept for the cases that need it.
When a microservices developer makes sense
- Several teams need to release on their own schedule.
- One part of the product needs to scale far more than the rest.
- Your monolith is hard to change, and every release feels risky.
- You are planning a new system that will grow into many parts.
- Your existing services are slow, flaky or hard to debug.
If you have a small team, a young product and one codebase that is easy to work in, you may not need this role yet. A microservices developer will tell you that honestly, and can help you keep the code in shape for a later split.
Reading a microservices developer’s background
Ask for a system they built or split, how many teams worked on it and what went wrong. Ask what they would do differently. Listen for specific answers about boundaries, failure and data. A list of tools tells you little, but a developer who can explain a trade-off, such as why they kept two services together, is usually a strong hire.
Interview questions to try
- How would you decide whether to split part of a monolith into a service?
- When would you choose gRPC or messaging over a REST call?
- How do you handle a task that touches the data of three services?
- How would you find the cause of a slow request that crosses many services?
- What do you do when a message is delivered twice?
The best answers give reasons and an example from past work. Be wary of a candidate who treats microservices as the answer to every problem.
Run a small paid exercise
Give each finalist the same small task from your real system. It could be a plan to split one module into a service, a review of how two services share data or a design for a safe release of a change that touches several services. Pay for the time. Then compare how they set boundaries, what risks they found, how they would watch the result and what questions they asked about your team.
Agree how the system is kept healthy
Agree where each service lives, who owns it and how a change to a shared contract is announced. Put contract tests and health checks into your pipeline, so a change that breaks another service is caught before it ships. Keep the repositories, the cloud account and the keys in your own name, with a separate login for each person. Then nothing is lost if the people change.
Settling in
Give your microservices developer access to the code, the cloud account, the monitoring tools and the people who own each part. A short walkthrough of how a request flows through your system helps more than a long document. A weekly call and one shared board keep progress easy to see. Share the known weak spots early, such as a service that fails under load or two services that always change together, because that is where a specialist adds value fastest.
Mistakes to avoid
- Splitting a small system into many services before there is a real need.
- Cutting by technical layer, so every feature touches every service.
- Sharing one database between services, which ties them together again.
- Skipping logs, traces and metrics until the first outage.
For related skills, see our Python developers when your services are written in Python, or our AWS developers when they run on that cloud.