Operations & Capacity

Plenty of teams run Kafka competently day to day but lack the specialist depth for the hard weeks: the capacity decision ahead of a traffic doubling, the rebalancing project, the incident that outlasts the first on-call rotation. We supply that depth by the hour.

Monitoring worth believing

We build or repair the observability layer around what actually precedes incidents: under-replicated and under-min-ISR partitions, ISR shrink rate, controller and metadata-log health, disk and request latency, consumer lag measured in time per group, and rebalance rates. Alerts map to SLOs on the flows the business cares about — not to every metric the exporter emits — so a page means something and gets believed.

Capacity from measurement

Capacity plans start from measured per-partition throughput under your real producer settings and durability requirements, not from instance-type folklore. We size brokers, storage, and partition counts against peak demand plus replay headroom — the capacity to drain an outage backlog at a multiple of produce rate — and write down the assumptions so the plan can be re-run when traffic changes.

Rebalancing and rescue projects

Uneven partition distribution, oversized brokers next to idle ones, thousand-partition topics nobody remembers creating: we plan and execute rebalancing with throttled data movement and measurable before/after distribution — on schedule, not during an incident.

Incident response

When a streaming outage exceeds your team's depth, an engineer who has handled broker failures, corrupted consumer offsets, runaway rebalances, and full disks joins your bridge, works the problem with your team, and leaves behind a post-incident review with the systemic fixes — because the goal of incident work is fewer incidents.