Insights and writing

Notes from the pager, not the whiteboard.

We write about the parts of a system that only show up under load: backpressure, idempotency, exactly-once delivery, the true cost of a Kubernetes fleet, and what it takes to run a language model in production without lying to yourself about the numbers.

What you are reading

A selection of what the team writes about.

This page is a selection, not an archive. The full posts, with the diagrams, load-test numbers, and the config we would not put on a public page, are shared with our clients and presented at Bratislava engineering meetups. If a topic below is relevant to a system you are building, tell us and we will send you the long version.

What we tend to cover

Backpressure Idempotency Streaming Kubernetes cost PostgreSQL RAG evaluation Observability Resilience FinOps
Published hereSelected notes
Full postsClients and meetups
CadenceRoughly monthly
Written byThe engineers

Featured

The one we get asked about most.

Platform and distributed systems / Backpressure

Backpressure is a product decision, not a library flag.

Most teams reach for a bounded queue, set a number that feels safe, and call it backpressure. Then a downstream dependency slows by 200 ms, the queue fills, and the failure that reaches the customer is a timeout with no explanation. The interesting question is not how large the buffer is. It is what the system promises to do when the buffer is full: shed load, reject with a clear signal, or degrade to a cheaper path. That promise belongs to the product, and it has to be decided before you write the consumer.

In this piece we walk through a real order-intake service that moved from an unbounded in-memory queue to explicit admission control at the edge. We cover why we rejected requests at the load balancer rather than the application, how we chose the shedding threshold from the p99 latency budget rather than from CPU, and the dashboards that let the on-call engineer see the difference between "slow" and "overloaded" in under five seconds. The result was a service that stayed truthful under a 4x traffic spike instead of quietly falling apart.

Backpressure Admission control Load shedding p99 budgets

2026-05-14 · Tomas Varga, Founder and Principal Engineer

More writing

Six problems we have written up.

Each one started as an incident review, a design document, or a talk. They map directly onto the four practices we run: platform, cloud, data, and applied AI.

Data and streaming · 2026-03-02

Idempotency keys that survive a retry storm

A payment webhook fires three times because the sender never saw your 200. We show the schema, the unique constraint, and the exactly-once window that keeps a double charge impossible even when the client retries hard.

Lucia Horvath, Lead Data Engineer

Data and streaming · 2025-11-18

Streaming exactly-once without the folklore

Exactly-once is a property of the whole pipeline, not a checkbox in the consumer. We trace one Kafka to warehouse path and show where transactions, offsets, and idempotent writes actually earn their keep, and where they do not.

Andrej Molnar, guest, Kestrel Logistics

Cloud and infrastructure · 2026-01-27

Kubernetes cost: where the money actually goes

Requests set too high, idle node pools, and cross-zone traffic no one budgeted for. We attribute spend per service, then walk the changes that cut a client platform bill by 62% without touching a single feature.

Marek Danko, Principal Site Reliability Engineer

Applied AI · 2026-04-09

RAG evaluation you can put in front of a regulator

A retrieval assistant is only as trustworthy as its eval harness. We describe the offline test set, the faithfulness and citation checks, and the guardrails that let a claims team ship 71% faster without loosening accuracy.

Peter Balaz, Lead, Applied AI

Platform and distributed systems · 2025-09-30

PostgreSQL at scale before you reach for a shard

Connection pooling, partitioning, and honest index discipline get you a very long way. We cover the write path of a real-time ledger at 12k transactions per second and the exact point where partitioning stopped being optional.

Jana Kovacova, Co-founder and Head of Platform

Cloud and infrastructure · 2025-12-11

Cutting mean time to detection from minutes to seconds

Alerts fire on symptoms, not causes, so on-call spends the first ten minutes guessing. We describe the trace-first observability model that took one client from a 22 minute detection time to under three.

Eva Krajcova, Head of Delivery

By practice

What each team is thinking about now.

The topics we write about follow the work. Here is what is on the whiteboard in each practice this quarter.

Timeout and retry budgets that compose across service hops, circuit breakers that fail closed instead of thrashing, and the write path of a double-entry ledger that has to settle in single-digit milliseconds. We keep coming back to one theme: a system that degrades on purpose beats a system that is fast until it is not.
Cost attribution per team on a shared cluster, right-sizing requests from real usage rather than guesswork, and observability that lets on-call tell the difference between a slow dependency and an overloaded one. The recurring lesson is that a platform bill is a design output, and you can steer it.
Idempotency keys and dedup windows, exactly-once semantics across Kafka and the warehouse, and schema evolution that does not break a consumer six months later. Most of these posts start life as a whiteboard argument about what "processed" really means.
Retrieval quality you can measure, evaluation harnesses that run in CI, and serving models behind guardrails with a clear rollback. We write about the boring parts on purpose, because the boring parts are what keep a model in production instead of in a demo.

Get the next one

Updates by email, when there is something worth sending.

We do not run a newsletter treadmill. When a post is ready, or when we are giving a talk in Bratislava, we send a short note with the link and a one-line summary so you can decide whether it is worth your time. No tracking pixels, no digests, no filler.

  • One email per postRoughly monthly, never on a fixed schedule for its own sake.
  • Written for engineersSpecifics, numbers, and failure modes, not marketing.
  • Easy to leaveOne click to unsubscribe, and we mean it.

There is no live form here. Send a note through the contact page and we will add you by hand.

Start

Recognise one of these problems in your own stack?

If a topic above maps onto a system you have to keep running, tell us the shape of it. We will send the full write-up and, if it fits, talk about building it with you.