{ }

kael.voss

work

stack

writing

now

◉ Berlin → Remote

● Available Q3 2026

12+ yrs shipping

PRINCIPAL · DISTRIBUTED SYSTEMS

Kael Voss.

I build the systems your systems run on.

Principal engineer focused on resilient distributed systems and the developer platforms teams actually want to use. I've spent a decade shipping the unglamorous infrastructure — schedulers, message buses, build systems, internal SDKs — that make product engineers fast.

12y

in production

47B

req/day at peak

99.99

% SLA shipped

6

OSS maintained

~/kael — zsh

$ whoami

principal_engineer

$ ls ~/focus/

distributed-systems/ developer-platforms/

observability/ api-design/

$ cat ./principles.txt

→ boring tech compounds

→ failure modes > happy paths

→ a good abstraction earns its weight

$ █

CURRENTLY SHIPPING

a multi-tenant scheduler in Rust.

// 01 — PHILOSOPHY

How I think about engineering.

The best engineering work I've seen looks unremarkable from the outside. A queue that drains. A deploy that doesn't wake anyone up. A migration that finishes with three engineers still asleep on a different continent. That's the bar I aim for — systems that get out of their own way.

I lean boring on stack choices and weird on internal abstractions. I trust observability over hunches, prefer simulation over reactive debugging, and treat documentation as infrastructure. Most of all, I optimize for the engineer who'll inherit this in two years — usually a version of me who's forgotten most of it.

distributed systems

platform engineering

observability

API design

technical leadership

// 02 — STACK & TOOLING

The tools I reach for.

Not a checklist. These are the ones I'd defend in a design review at 4pm on a Friday.

⟨/⟩

Languages

Rust for systems work where memory and latency budgets matter. Go for services. TypeScript for everything customers touch. Python when the data wants to talk back.

Rust

Go

TypeScript

Python

Elixir

Infrastructure

Kubernetes when it earns its place, raw EC2/Fly when it doesn't. Terraform for the boring stuff. Pulumi when I want types. Postgres until proven otherwise.

Kubernetes

Terraform

AWS

Postgres

Pulumi

Data & Messaging

Kafka for the high-throughput stuff, NATS when latency wins. ClickHouse for analytics that need to feel instant. Temporal for workflows that absolutely cannot drop.

Kafka

NATS

ClickHouse

Temporal

Redis

Observability

OpenTelemetry everywhere. Prometheus + Grafana for the dashboards engineers actually use. Tempo for traces. Honeycomb when the question matters more than the metric.

OpenTelemetry

Prometheus

Grafana

Honeycomb

// 03 — SELECTED WORK

Things I've built, shipped, and learned from.

Three projects that taught me the most about systems, teams, and the gap between what spec docs say and what production demands.

PROJECT 01

OPEN SOURCE

Helix Scheduler

Multi-tenant workload scheduler · Rust

A bin-packing scheduler that hands out compute across noisy-neighbor-prone tenants without dropping latency budgets. Wrote the constraint solver, the gossip-based membership layer, and the admission controller. Now scheduling ~3.2M jobs/day in production.

p99 < 4ms

Admission decision

3.2M/day

Jobs scheduled

2.1k★

GitHub stars

// scheduler/admission.rs

pub fn admit(req: &Request) -> Decision {

let budget = self.tenant.budget();

if budget.would_exceed(req) {

return Decision::Defer(backoff);

}

self.solver.place(req).into()

}

[ARCHITECTURE]

edge →

ingest

kafka

stream-proc

clickhouse

materializer

dashboards

→ p95 query latency dropped from 8.2s to 340ms

PROJECT 02

INTERNAL

Atlas Telemetry

Real-time telemetry pipeline · Go + ClickHouse

Replaced a creaking Elastic stack with an OpenTelemetry-native pipeline. 47B events/day, sub-second query latency on the dashboards engineers actually open at 3am. Cut infra cost by 64% along the way.

Go

ClickHouse

Kafka

OTel

PROJECT 03

PLATFORM

Tideway Deploy

Internal developer platform · TypeScript + K8s

The deploy tool 220 engineers use every day. Built on Kubernetes, Argo, and a thin TypeScript control plane. Median time-to-prod went from 47 minutes to 6. Most importantly, on-call pages from broken deploys dropped 71%.

Atomic rollouts with automatic rollback on SLO breach

Service catalog + ownership routing for incidents

Cost dashboards engineers can read without a PhD

BEFORE / AFTER

Median deploy

47 min → 6 min

−87%

On-call pages

21/wk → 6/wk

−71%

Eng adoption

0 → 220 engs

100%

// 04 — EXPERIENCE

Where I've shipped from.

Twelve years across infra teams, platform orgs, and the occasional startup — building the stuff product engineers stand on.

2023

now

Helios

Principal Engineer · Platform

·

REMOTE

Tech lead for the platform group (~30 engineers). Drove the org-wide migration from monolithic deploys to a service-mesh-backed platform. Designed the SLO program, wrote the RFC process, and rebuilt the on-call rotation around alert quality, not alert volume.

Platform Engineering

RFC Process

SLO Program

Tech Leadership

2019

2023

Cordoba Systems

Staff Engineer · Infrastructure

·

BERLIN

Rebuilt the global payments backend during hypergrowth. Designed the idempotency layer that survived a 50× traffic spike on a Black Friday I'd rather not relive. Mentored 4 engineers from senior to staff, including one who now runs the team.

Payments Infra

Idempotency

Mentorship

2016

2019

Northwind Labs

Senior SWE · Backend

·

AMSTERDAM

Owned the API gateway and ingestion pipeline. Migrated us from a fragile monolith to Go microservices over 18 months — and somehow nobody noticed in prod. Also wrote way too many bash scripts.

API Gateway

Microservices

Migrations

2014

2016

Tessellate.io

Software Engineer · First hire

·

STARTUP

Wore every hat. Built the first version of the product, the deploy pipeline, the on-call schedule, and the awful interview rubric I'd later spend years apologizing for. Acquired in 2016.

Full-stack

0→1

Acquired

// 05 — IMPACT

Numbers I can defend.

Selected metrics from the past five years. Happy to walk through how I got each of them — including the ones I'd do differently now.

47B

REQUESTS / DAY

Peak load handled by the telemetry pipeline I designed at Helios.

99.99%

SLA SHIPPED

Three years running on the payments backend at Cordoba. Two near-misses, zero region-wide outages.

−64%

INFRA SPEND

Replaced the Elastic stack with ClickHouse. Saved ~$2.1M/yr without losing query power.

220

ENGS ON PLATFORM

Every engineer at Helios uses the platform I built. NPS held at +52 through two re-orgs.

WORK I'M MOST PROUD OF

An on-call rotation engineers actually look forward to.

Spent a year killing every flaky alert and rewriting runbooks around symptoms instead of metrics. Net result: pages dropped 71%, MTTR halved, and one engineer told me on-call "finally feels respectful." Most underrated thing I've shipped.

−71%

FEWER PAGES

// 06 — OPEN SOURCE

Things I maintain in the open.

Some I started, some I just keep alive. All of them I'd happily talk you through.

kael/helix

★ 2.1k

Multi-tenant scheduler in Rust. The project from the case study above, now run by a small community of contributors.

Rust

Apache-2.0

kael/otel-sketch

★ 890

OpenTelemetry processor that samples on cardinality, not just rate. Used by a handful of mid-size SaaS companies in prod.

Go

MIT

kael/cargo-explain

★ 1.4k

A cargo subcommand that explains compiler errors in plain English. Started as a weekend joke; now a real tool. Featured in This Week in Rust.

Rust

MIT

// 07 — WRITING & TALKS

What I think out loud.

Essays and conference talks on distributed systems, platform engineering, and the boring discipline of running production.

ESSAY · 2026

On-call as a craft, not a punishment.

How we rebuilt the rotation at Helios around symptom-based alerting and finally got engineers to volunteer for shifts.

TALK · KUBECON '25

The scheduler we wish someone had warned us about.

A war story about default kube-scheduler behavior under multi-tenant load — and what we built instead.

ESSAY · 2025

Documentation is infrastructure.

Why I budget docs work alongside services, with the same SLOs, and what changed when we did.

TALK · SREcon '24

Idempotency keys at 50× traffic.

A walkthrough of the Black Friday that almost broke our payment system — and the design we'd ship today.

// 08 — CREDENTIALS

Education & continuing study.

M

MSc Computer Science

ETH Zürich

2012 — 2014

B

BSc Computer Engineering

TU Delft

2009 — 2012

AWS Certified Solutions Architect

Professional · current

RENEWED 2025

Distributed Systems Cohort

MIT CSAIL · advanced topics

2023

// 09 — KIND WORDS

What collaborators say.

Pulled from references and Slack DMs I asked permission to quote. Happy to put you in touch with any of them.

"

Kael writes designs the way most people wish docs read: tight, honest about tradeoffs, and never trying to sound smart. I learned more reading his RFCs than I did in two grad classes.

MO

Marcelo Ortega

Director of Eng · Helios

"

He's the engineer I want around when something is on fire AND when nothing is. Calm during incidents, relentless during planning. Took our infra from rumor-driven to actually instrumented.

PV

Priya Venkat

VP Infrastructure · Cordoba

"

Kael mentored me into staff. Not by being nice — by being honest. He gave me the kind of feedback I couldn't have gotten anywhere else, and the trust to act on it.

JK

Jonas Kessler

Staff Engineer · Cordoba

// 10 — NOW

What I'm into this season.

Updated whenever something changes. Inspired by /now pages everywhere.

BUILDING

A multi-tenant scheduler in Rust that doesn't make me hate noisy neighbors.

READING

Designing Data-Intensive Applications (again), and the Tigerbeetle design docs.

ADVISING

Two infra startups (seed + Series A) on platform direction and hiring.

AWAY FROM

Kubernetes operators. I love them. I need a break.

// 11 — CONTACT

Let's build something worth running.

Open to senior IC roles, tech-lead positions, and selective fractional engagements with infra or platform teams. I'll respond to anything that isn't a recruiter blast.

$

© 2026 Kael Voss · Berlin

designed in vim · deployed on a tuesday

Designed onimyme· Create yours