Which messaging system do you use?

Kafka when you need to keep a history of events and process a large volume of messages. RabbitMQ for classic task queues, and NATS when simplicity and speed matter most. We choose based on how your services communicate, not on trends.

Is Kubernetes required?

No. For five services, Nomad or Docker Swarm are often enough and cheaper to maintain. Kubernetes pays off from around fifteen services or when the system has to run in several regions.

/ software development

Microservices and scalable architecture

We split a large system into smaller parts that can grow and change independently, but only when there is a real reason to.

Microservices are not a goal in themselves. They solve specific problems: one part of the system has to handle far more load than the rest, several teams cannot work at the same time without getting in each other's way, or a failure in one part takes down the whole system. In those cases we split the system gradually, following a clear plan, while the old system keeps running.

Start a project Services

What you get

An analysis of your business and a clear map of which parts the system should be split into
Reliable communication between parts of the system, so data is not lost even when one part is temporarily down
Central monitoring of the whole system, so problems are found quickly even when they span several services
Each part gets new versions on its own schedule, released to a small share of users first, with an automatic rollback if something goes wrong
Clear instructions for your team on what to do when something breaks

When to call us

Every release takes half an hour and everyone worries something will break
One part of the system is under heavy load and drags everything else down with it
Several teams work on the same code and keep waiting on each other
You cannot afford downtime while you release a new version

How we work

We start with an analysis and a workshop where we map with your team how the business really works. Then we pick the first part to separate, the one with the lowest risk and the biggest payoff, and move it out while the rest of the system keeps working as before. Once monitoring and releases are in place, we move the remaining parts in controlled steps, and we never rewrite the whole system at once.

Frequently asked questions

Often, no. Many companies that ask us to "break up" their system actually have a different problem. If releases are slow because of tests, the fix is better tests, and if teams keep colliding in the code, the fix is better organization. Microservices are expensive and do not solve those problems.

Related services

Software development

Tell us what you need

Send a short description of your project and we'll get back to you within 24 hours to set up a call.

Send an inquiry See services