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.
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
Budget and guarantees
We fix the expected load and latency and what the system must guarantee when something fails.
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.
Load tests
k6 scenarios with a realistic profile, measuring p95 and p99 and not only throughput.
Invariant checks
After load and failures we verify the final state: no lost and no duplicated effects.
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
The primary language for high-load services.
Data
Queues and events
Verification and observability
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 load08Contact
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.
- Telegram@missuk2003
- Emailceo@closeflow.ru
- GitHubHusqvarnalox