Backends & APIs

Services, APIs and integrations that hold under load and are still legible to whoever reads them next year.

Go
Python
Node
TypeScript
Postgres
Redis
Kafka
OpenAPI

Backends fail slowly. They work fine until a retry storm, a partner outage or a migration at the wrong hour turns a small assumption into an incident. We build the version that degrades instead of collapsing.

Practically that means designed API contracts with versioning and generated clients, background work on a real queue with retries and dead-letter handling, idempotency on anything a client can call twice, and migrations that can run while traffic is live. None of it is exotic — it is just rarely scoped, so it rarely gets built.

We are equally happy inside a well-kept monolith as in a service mesh, and we will argue for the monolith more often than most consultancies. Splitting a system into services before the team has the operational muscle for it turns one deployment problem into fifteen.

What you get

Documented HTTP or gRPC API with versioning and generated clients
Background jobs and queues with retries, backoff and dead-letter handling
Third-party integrations with timeouts, circuit breaking and honest failure modes
Database schema and migrations you can run in the middle of the afternoon

Common questions

Can you work inside our existing monolith?

Yes, and we would rather do that than propose a rewrite. A monolith that is well factored and well tested beats a distributed system nobody can debug. We will suggest extracting a service when there is a real reason — a different scaling profile, a different team, a hard compliance boundary.

Do you do performance and scaling work?

Yes: profiling, query plans, indexing, caching layers and load testing. We start by measuring, because often enough the answer is an index or a query plan rather than the architecture change a team is bracing for.

Can you own on-call while you are engaged?

For work we built, during an agreed window, yes. We will not take blanket on-call for a system we did not write and cannot change — that arrangement helps nobody at 3am.

Next step

Tell us what has to ship, and by when.

One call, no deck. If we are not the right team for it we will say so, and usually point you at who is.

Start a conversation branislav@thrivee.io

Typical reply within one business day · CET / CEST (UTC+1 / UTC+2)