Backend Engineer, Distributed Systems
Summary
Backend engineer building the distributed core of Kloudfuse's observability data lake: owning storage (ingestion, indexing, compaction, tiering), pushing the distributed query engine, and designing multi-tenant isolation and cardinality control. Core stack is Go and Java with Kafka, Pinot, Flink, and Kubernetes.
What you’ll work on
Own the storage layer of the observability data lake: ingestion pipelines, segment layout, indexing, compaction and tiering across hot and cold storage.
Push the query engine: distributed planning and execution, predicate pushdown, vectorised scans, and the cost model that decides between them.
Hold the line on cardinality. Design the encodings, sketches and rollups that keep millions of series affordable rather than merely possible.
Build multi-tenant isolation that holds under load — quotas, admission control and backpressure that fail predictably instead of loudly.
Make correctness observable: consistency guarantees, replay and repair paths, and the tests that prove them before a customer does.
What we look for
Deep, hands-on experience with distributed data systems — a database, stream processor, search engine, time-series store or query engine you helped build and run.
Fluency in the fundamentals that decide these systems: consensus, replication, partitioning, consistency models and failure semantics.
A performance instinct grounded in measurement — you profile, you read the flamegraph, and you know where the bytes and the cache misses went.
Comfort in Go or Java at production depth, and willingness to work in either.
Engineers who operate what they build. On-call for your own system is part of the design feedback, not a chore bolted on afterwards.
Bonus
Internals of Apache Pinot, Druid, ClickHouse, Kafka, Flink, Lucene or Parquet — as a contributor or as someone who has debugged them in anger.
Columnar and time-series storage internals: encodings, compression, zone maps, bloom and inverted indexes, cache behaviour.
Query language and planner work — parsing, rewriting or optimising PromQL, SQL or something like them.
Observability, APM or monitoring domain experience.
How we work
Small team, short feedback loops, real ownership from week one.
You’ll talk to customers, engineers debugging real incidents, and that shapes what you build.
We ship, then iterate; bias toward hands-on building over process.
Modern tooling is encouraged, including AI-assisted development.
Team: Engineering
Location: Cupertino / Remote
Type: Full-time
Stack: Go · Java · Kafka · Pinot · Flink · Kubernetes
Skills
As published by ashby · 3 questions · 2 written answers
Basics
Name, Email, Resume, Location
Short answers (1)
- LinkedIn profile URL
Written answers (2)
- What are you proud of building? Name the system, your part in it, and the result.
- Describe a production issue you debugged end to end: what broke, how you found the cause, and what you changed.
