Practice 01 / Platform

Platform and distributed systems.

We build the request-serving core of your product: high-throughput APIs, event-driven services, and the stateful systems that must never lose a write. Then we prove they hold their latency and availability budgets while traffic climbs and dependencies misbehave.

What this practice covers

Systems that stay fast and correct under load.

Most outages are not caused by a single bad line of code. They come from a slow dependency, a retry storm, or a queue that quietly grows until it topples the service holding it. We design for those failure modes from the first architecture session, not after the first incident.

The work spans four areas. High-throughput APIs and gRPC services that keep tail latency flat as concurrency rises. Event-driven services that decouple producers from consumers and absorb spikes without dropping work. Stateful cores such as ledgers and durable queues, where a lost or double-applied write is a real financial problem. And the resilience layer that ties them together: backpressure, circuit breakers, timeouts, and graceful degradation, so a partial failure stays partial.

We treat service level objectives as engineering constraints, not marketing numbers. Every system we ship carries explicit targets for p99 latency, availability, and throughput, plus recovery targets for the day something goes wrong. We instrument against those targets so you can prove them, and we load test to the point where the system starts to bend before your customers find that edge.

Discuss your platform See platform work

Example SLO targets

p99 API latencyUnder 50 ms

p999 API latencyUnder 200 ms

Availability99.98% monthly

Throughput50k req/s sustained

Error budget0.02% per 30 days

RPOUnder 5 s

RTOUnder 2 min

Targets set per system, then measured

What we build

Four kinds of system, one engineering standard.

These are the components we are asked for most. In practice an engagement usually combines several of them, since a serious platform needs an API surface, an event backbone, durable state, and a resilience story that connects all three.

APIs and gRPC services

Request-serving services with a clear contract, versioned schemas, and idempotent writes. We tune connection pooling, timeouts, and concurrency limits so tail latency stays flat as load grows, and we ship gRPC for internal hops where the wire cost actually matters.

Event-driven architecture and messaging

Kafka and log-based messaging with well-defined topics, partition keys, and consumer groups. We decouple producers from consumers so a slow downstream service becomes lag to work off, not a cascade of failed requests upstream.

Resilience engineering

Backpressure, circuit breakers, bounded queues, request hedging, and graceful degradation. When a dependency slows down, the system sheds load in a controlled way and keeps serving what it can, instead of exhausting threads and taking everything with it.

Stateful systems

Ledgers, durable queues, and workflow state where correctness is not optional. We use the transactional outbox pattern, idempotency keys, and exactly-once effective processing so a retry or a redeploy never double-applies a write or leaves a partial transaction behind.

How the pieces fit

Design for the failure, not just the happy path.

A distributed system is a set of promises between services. We make those promises explicit, then build the machinery that keeps them when a node dies, a network partitions, or a deploy goes out mid-flight.

Bounded everythingEvery queue, pool, and buffer has a limit. Unbounded growth is the most common way a healthy service turns into an outage.
Idempotent by defaultWrites carry idempotency keys so a client retry or a consumer replay is safe, which is what makes at-least-once delivery workable.
Isolation of blast radiusBulkheads and per-dependency circuit breakers keep one slow call from consuming the whole service.
Observable by constructionGolden signals, structured traces, and SLO burn-rate alerts are part of the build, not bolted on after launch.

SLO as code

The targets live next to the service.

We keep objectives, budgets, and resilience limits in version control alongside the service they govern. A change to a latency target or a circuit-breaker threshold goes through review like any other code, and the alerting is generated from the same file.

Go Rust gRPC Kafka PostgreSQL OpenTelemetry

ledger-api.slo.yaml

# service level objectives, checked in CI

service: ledger-api

objectives:

latency_p99_ms: 50

availability: 99.98

throughput_rps: 50000

resilience:

timeout_ms: 250

breaker: "open at 5% errors / 10s"

queue_max: 2048

degrade: "serve cached balance, reject writes"

recovery:

rpo_seconds: 5

rto_seconds: 120

> slo lint ok, burn-rate alerts generated

Reference targets

What good looks like, by system type.

These are starting points we tune to your traffic and risk profile. A read-heavy API and a financial ledger do not deserve the same budgets, and we set them accordingly.

System type	p99 latency	Availability	Throughput	RPO / RTO
Read API	Under 30 ms	99.95%	80k req/s	Cache-backed / under 1 min
Transactional API	Under 50 ms	99.98%	50k req/s	Under 5 s / under 2 min
Event pipeline	Under 100 ms end to end	99.9%	3.5M events/s peak	Replay from log / under 5 min
Ledger core	Under 40 ms settle	99.99%	12k tx/s	Zero data loss / under 2 min

Related work

This practice, in production.

The Nordbank ledger is a working example of everything on this page: a stateful core, exactly-once effective writes, and a strict latency budget under real transaction load.

Fintech / Ledger

Real-time ledger for Nordbank

A double-entry core that settles balances the moment a transaction lands, built on an outbox and idempotent writes so a retry never double-posts. We removed an overnight batch and held four nines of uptime.

12k/sTransactions

40 msp99 settle

99.99%Uptime

ECORTIQ took a ledger we were afraid to touch and turned it into the most reliable service we run. They understood the failure modes better than we did.

Jonas Keller

VP Engineering, Nordbank

What carried over

Outbox patternWrites and events committed in one transaction.
Idempotency keysSafe retries across the whole write path.
Load tested to failureWe found the ceiling before customers did.

Read the case study

Common questions

What technical buyers ask us first.

We avoid distributed transactions across service boundaries because they are fragile and slow. Instead we keep the write and its event in one local database transaction using the transactional outbox pattern, then publish that event reliably. Consumers process it with idempotency keys, so at-least-once delivery becomes exactly-once in effect. Where a business process spans services, we model it as a saga with explicit compensating actions rather than pretending a two-phase commit will hold.

We test with realistic traffic shapes, not a flat request rate: bursts, hot keys, and slow dependencies injected on purpose. We push past the SLO target until tail latency breaks down, so we know the real ceiling and the failure mode, not just the number in the contract. We watch p99 and p999 latency, error rate, saturation of pools and queues, and how the system behaves when a dependency is throttled. The output is a documented headroom figure and a list of the first things that bend under stress.

Either works, and we plan for both from the start. Some clients want managed operations with defined SLOs and 24/7 on-call, and we carry the pager. Others want to run it in-house, so we deliver runbooks, dashboards, alert definitions, and a clean architecture document, then pair with your team through the first weeks of live traffic. We never leave you with a system only we can operate.

It starts with a two-week discovery and architecture phase at a fixed fee, where we map constraints, failure modes, and data flow. From there, our median time from kickoff to a first release in production is about six weeks, because we ship a thin working path early and widen it. A full stateful core with hardening, load testing, and an on-call plan usually runs three to five months, staffed by two to five senior engineers.

See how an engagement runs

Start

Have a platform that has to hold?

Tell us the throughput, latency, and availability you need, and where the current system hurts. We will tell you honestly whether we are the right team for it.

Start a project See all capabilities