Discuss a project
Discuss a project

Services / High-load

High-Load and Performance-Critical Systems

Closeflow designs backend systems that have to carry a large stream of events, respond quickly and not fall over under overload. The core is Go, PostgreSQL, Redis and message brokers; behaviour under load is verified by measurement, not by assumption.

  • Go · PostgreSQL · Redis · Kafka
  • queues · backpressure
  • k6 · p95/p99
  • contract · NDA

02Problems

What we work on

  • High event volume

    Intake and processing of events that arrive faster than they can be handled synchronously: queues, batching, parallel workers.

  • Strict latency requirements

    Responses fit a p95 and p99 budget, not just the average. We find where time goes: database, network, locks, serialization.

  • Overload and degradation

    The system must refuse predictably: limit intake, keep queues bounded and avoid cascading failure.

  • Correctness under retries

    The broker delivers a message twice, a worker dies halfway. The side effect must still happen once.

  • PostgreSQL bottlenecks

    Indexes, query plans, locks, connection pools, hot rows, and partitioning where it is justified.

  • Isolation and resources

    Running untrusted code or heavy jobs under CPU, memory and time limits.

03Approach

How we do it

  1. Budget and guarantees

    We fix the expected load and latency and what the system must guarantee when something fails.

  2. Simple architecture first

    We start with an understandable design and measure. Complexity such as Kafka, sharding or caching is added where measurement showed the need.

  3. Load tests

    k6 scenarios with a realistic profile, measuring p95 and p99 and not only throughput.

  4. Invariant checks

    After load and failures we verify the final state: no lost and no duplicated effects.

  5. Observability

    Metrics, logs and tracing that show queues, latency and errors before a user complains.

04Proof

execute-once: reliability you can reproduce

Execute-once is an open repository of reproducible reliability tests. It checks duplicate events, relay failures, p95 and p99 metrics and invariants of the final state. The point is that the claim “the effect happens exactly once” can be verified by running it, not by taking our word.

Code: github.com/Husqvarnalox/execute-once.

05Experiment

sandboxd: an experimental project

sandboxd is a Go daemon for process isolation: Linux namespaces, cgroup v2, seccomp, a bounded scheduler, an HTTP API, SSE log streaming and Prometheus metrics. It is experimental. It is not a ready commercial container engine, but a working demonstration of how we approach isolation and resource limits.

Code: github.com/Husqvarnalox/sandboxd.

06Stack

Tools

Language

  • Go

The primary language for high-load services.

Data

  • PostgreSQL
  • Redis

Queues and events

  • Kafka / Redpanda
  • Asynq
  • outbox / inbox

Verification and observability

  • k6
  • Prometheus
  • Grafana
  • OpenTelemetry

A system that cannot take the load?

Describe the load profile, the bottlenecks and the constraints. We will say what can be measured and fixed, and whether we take it on.

Discuss the load

08Contact

Tell us what
has to work.

Describe the problem, your current system and its constraints. If it’s a good fit, we’ll suggest a next step — usually a short call about data, integrations and timelines.

brief.form4 fields · 2 minutes

Budget optional