Farhan Ali KhanOpen to new roles

Software engineerStorage and distributed systemsBengaluru

Tap the lid, a drive, or the lights

Scroll to draw

Your turn

Got a system that has to hold?

Farhan Conf · 2013 to 2026 · Bengaluru

Talks

Talks on the wall open each job’s world. Passes take you down the stack.

Layer 01 · Interface

TCS

Associate engineer · 2013 to 2014

Where it started: enterprise portals, built by hand.

  • Custom SharePoint 2013 and 2010 solutions in Visual Studio for enterprise clients.
  • Web parts, site definitions, designer workflows, event receivers and timer jobs.
  • HTML5, CSS3 and JavaScript; the server and client object models.

Layer 02 · Product APIs and access

HapPay

Infrastructure lead · 2015 to 2017

Who may do what, and money that has to add up.

  • Designed and built role-based access control for the hierarchy of users in each customer organisation.
  • The public API partners integrated with, and accounting sync into SAP, Oracle, QuickBooks and Tally.
  • Ran, scaled and migrated the critical MySQL and PostgreSQL databases; Docker, AWS and the ELK stack.

Layer 03 · Data pipelines and caches

GreedyGame

Data engineering lead · 2017 to 2019

An auction in under 500 ms, half a billion times a day.

  • Designed the real-time bidding protocol, with every response under 500 ms for more than 500 million requests a day.
  • Built the first data pipelines on Kafka and BigQuery, ingesting more than 2 TB a day; Parquet and Cap'n Proto.
  • Caching on Redis and Aerospike, and the Prometheus and Grafana dashboards the business scaled by.

Layer 04 · Membership and replication

Cisco

Senior engineer · 2019 to 2021

Routers that agree without asking a primary.

  • Moved firewall deployments from a centralised architecture to peer to peer, a Go layer beside Snort on each router.
  • A SWIM gossip membership mesh across routers with HashiCorp memberlist and Serf.
  • An in-memory key-value store gossiped across the cluster with Lamport clocks, and a CRDT successor.

Layer 05 · Platform and orchestration

VMware

Senior engineer · 2021 to 2022

One platform every team deployed to, under every compliance rule.

  • Kubernetes operators for multi-cluster management across clouds: federation and multi-tenancy.
  • A self-service model for curated apps (Kafka, Vault, Prometheus) with the team's practices built in.
  • Clusters for development, staging, production and sensitive workloads under PCI, HIPAA and FedRAMP High.

Layer 06 · Database internals

Codenotary

immudb · 2022 to 2023

Deleting data from a database built to prove nothing changed.

  • Data retention: efficient deletes in a database where proofs and storage are interlinked.
  • Compaction and key-value store performance.
  • New features, core components and testing for immudb, and its community.

Layer 07 · Storage engine and key-value

SurrealDB

Storage team lead · 2023 to 2026

The engine at the bottom: where the bytes finally land.

  • Built SurrealKV, an LSM-tree key-value store in Rust, from scratch, and made it performant.
  • A copy-on-write B+ tree, RocksDB tuning, and low-level work on vart and other in-memory crates.
  • Object storage under the LSM for a lakebase; the TAPIR distributed transactional store; DST across products.

Each role, a layer deeper

  1. TCS Interface
  2. HapPay Product APIs and access
  3. GreedyGame Data pipelines and caches
  4. Cisco Membership and replication
  5. VMware Platform and orchestration
  6. Codenotary Database internals
  7. SurrealDB Storage engine and key-value

How I work · 1

First, who is stuck?

A customer whose queries are slow. A team whose upgrades keep breaking. A system that falls over under load. I find the person first, and ask what "fixed" would look like to them.

How I work · 2

Then, first principles.

What must the system guarantee? Where does the time actually go? Which constraints are real, and which are just how it has always been done? Tools come last.

How I work · 3

Keep it steady, or start again.

Customers live on what is already running, so most days the right fix is a careful one: a simpler design, a better data layout, an upgrade nobody has to dread. Some problems outgrow their foundations, and then I build from scratch, the way the storage engine at SurrealDB was. Knowing which day it is, is the job.

How I work · 4

Read the paper. Build it small.

Gossip membership, real-time bidding, distributed transactions: I read the original papers and write a small version myself before I depend on someone else's. It is how I have moved between industries without starting from zero.

Then I own the outcome, in production.

Agents write the code. Proofs decide.

Prove it.

Code is cheap now: an agent writes a thousand lines before lunch. Knowing they are right is not. So I start from what must always be true. A TLA+ model checks the design before any code exists, and a stack of correctness and quality checks holds the code to it: proofs where it matters most, property and mutation tests, and deterministic simulation. The agents write; the checks decide. It is the loop I build with every day, and it holds.

\* what must always be true
Inv == \A t \in Txns :
  Committed(t) => Durable(t)
  1. TLA+the design
  2. Proofsthe critical pieces
  3. Property and mutation teststhe edges
  4. Deterministic simulationone seed, replayable

Model checking: 0 of 28 distinct states

Based inBengaluru.

Home, and the base for every role since 2013. Rain trees, filter coffee, and the city best seen from a bike.

From Bengaluru, with teams in London and the US

My day meets yours.

Bengaluru--:--
London--:--
New York--:--
San Francisco--:--
Bengaluru
London
New York
San Francisco
now

Hours in Bengaluru time. Shaded: where your working day meets mine.