I care about what happens to data before anyone models it.
Most of the interesting failures in a data platform never happen in the model. They happen three systems upstream, in a schema nobody owned, in a CDC stream that quietly dropped a column, in a join that was fine until the partition skewed. That is the layer I work at.
At Hewlett Packard Enterprise I design and operate the batch and streaming pipelines behind the Distributed Data Platform:
| Scale | What it means |
|---|---|
| 1+ TB / day | processed across batch and streaming pipelines, with reliable CDC and low-latency sync |
| 15+ BI data models | delivered for Customer Success, FinOps and Engineering |
| 95%+ | production incident SLA compliance |
Most of my week is spent on the unglamorous half of that picture: partitioning and join strategy when a table outgrows its plan, resource tuning on Kubernetes, and the alerting that tells us something broke before a dashboard does.
RaftDB, a mini distributed database written from scratch. I did not want consensus,
recovery and query optimization to stay black boxes, so I built them: Raft consensus with
leader election and log replication, a storage layer with WAL, snapshots, SSTables, Bloom
filters and background compaction, and a cost-based SQL layer on Apache Calcite over the
top.
Java · Raft · LSM Tree · RocksDB · Apache Calcite
Data quality research, working toward a cloud-native data quality framework for open-source datasets. Right now that means reading widely across validation systems, error detection, label noise and LLM-driven cleaning, and writing up what actually holds.
Public experiments: AIOps Platform · JanusGraph · Airflow + Spark · MCP Server · MLflow · Scala REST API
Data
Languages
Platform
Observability
B.Tech Computer Science & Engineering, Vellore Institute of Technology · 8.81 / 10
Interested in distributed systems, database internals, performance engineering and AI-powered data platforms.