Skip to content
Open to systems / quant-dev roles

I build systems wheremicroseconds and correctnessboth matter.

I write the layer everything else sits on — concurrency, compilers, lock-free data structures, and the network code that ties them together. Today a data engineer; aiming at the hardest problems in low-latency and large-scale data infrastructure.

amogh@systems: ~
run a command
whoami
amogh ramesh
roledata engineer
basedbangalore, india · IST
0
LeetCode solved
0
Hard problems solved
0
Built from scratch

Merged-PR count derived from GitHub PR state · re-synced every 6h

01Selected Work

Things I built from the metal up.

012024
Systems · C++

Tez

An HTTP/1.1 server in C++, written by hand on top of Boost.Asio.

A web server where the protocol, routing, threading and caching are all written by hand — only the socket and event layer is delegated to Boost.Asio. The HTTP/1.1 request lifecycle, a hand-rolled thread pool, and an LRU cache, with no web framework above the I/O edge.

The hard part — Owning every layer that demonstrates systems understanding — manual parsing, a real concurrency model, persistent connections — without reinventing the async event loop that a production library already gets right.

  • Manual HTTP/1.1 parsing, routing and response building — keep-alive, Content-Length, 400/413/431 limits — on top of Boost.Asio's io_context.
  • Hand-rolled fixed-size thread pool (std::thread + queue + condition_variable, enqueue() returning std::future), sized to hardware_concurrency().
  • Dual mutex-guarded LRU layer (response + file caches, 60s TTL) and RAII cleanup throughout — workers joined on shutdown, sockets lifetime-managed.
C++17Boost.Asiothread poolHTTP/1.1Docker
Read the case study
022024
Compilers · C++

minilang

A compiler with three of my own LLVM optimization passes.

A small language (single f64 type, functions, if/else, loops) lowered through a hand-written lexer, recursive-descent parser, AST and LLVM IR codegen — then optimized by three original passes I wrote on LLVM's new pass manager. Built on the Kaleidoscope tutorial's front end as a known-good baseline, with the middle-end as the real contribution.

The hard part — The LLVM Kaleidoscope tutorial stops before the part that demonstrates backend competence: writing your own optimization passes on the modern pass manager and measuring what they do to the IR.

  • Three hand-written passes on the new pass manager (PassInfoMixin): constant folding, dead-code elimination, and loop-invariant code motion.
  • Measured IR reductions up to −39% (05_invariant: 49→30 lines), reproducing the committed BENCHMARKS.md table exactly.
  • Builds against LLVM 18.1.8, JIT-executes correctly (fib(10)=55), with a green GitHub Actions matrix across Linux/macOS × Debug/Release.
C++17LLVM 18new pass managerORC v2 JITCMake
Read the case study
032025
Concurrency · Go
Private · guided study

SplitOrderedLists

A lock-free hash table in Go that grows without locks or rehashing.

A lock-free, extensible hash table implementing the Shalev–Shavit split-ordered design in Go: a single sorted lock-free linked list with buckets as pointers into it. Growth doubles the bucket count with an atomic CAS and moves no data. Implemented as a guided study under a supervising professor.

The hard part — Resizing a hash table while many goroutines read and write concurrently — using only atomic compare-and-swap, no mutex on the hot path, no stop-the-world rehash. Get the memory ordering wrong and it corrupts silently under load.

  • Shalev–Shavit split-ordering: bit-reversed keys over one sorted lock-free list, with buckets as lazily-initialized pointers — growth adds pointers, never moves data.
  • Harris two-phase delete + Michael revalidation, with the mark bit packed into an unsafe.Pointer and mutated only by CAS for zero-allocation reads.
  • 16 concurrent tests under Go's race detector; benchmarked against sync.Map, a sharded map, and a global-mutex baseline on a 64-core EPYC socket.
Goatomic CASlock-freeHarris/Michael listgenerics
Read the case study
042025
Full-stack · Infra

CodeCraft

An Educative-meets-CodeCrafters platform with Docker-sandboxed grading.

A coding-education platform pairing structured multi-lesson courses with hands-on 'build your own X' challenges — staged progression, automated grading, instant feedback. Every learner submission runs in a throwaway, network-isolated Docker container across four languages.

The hard part — Safe execution: running arbitrary, learner-submitted code on the server, in four languages, without letting it touch the network, the host, or another submission.

  • 23 build-your-own challenges (304 stages, 855 grading test cases) and 7 structured courses (59 modules, 617 lessons), all filesystem-defined.
  • Every submission graded in a fresh container — --rm, --network=none, --read-only, --cpus=1, --pids-limit=64, memory cap, 10s timeout — across gcc/go/python/node images.
  • ~50.6k lines of TS/TSX, 36 API route handlers, 123/123 tests green in CI, packaged as a docker-compose stack behind Caddy auto-TLS.
Next.js 16TypeScriptPrismaDockerMonacoCaddy
Read the case study
02Open Source

Upstream, where the review bar is unforgiving.

Pull requests to projects I don't own — three merged by project maintainers, three open and under review. Every one is linked, so you can check the status yourself.

03Writing

Notes on performance, systems, and design.

Long-form pieces on low-level performance, systems, and design — published on Medium, including in Java Guides.

Latest · in Java Guides

Java Input Method Performance Analysis: Scanner vs BufferedReader vs FastReader for CP

Read on Mediumjavacompetitive-programmingcomputer-science
04Stack

The tools I reach for, by layer.

01

Systems & Low-Latency

where my attention lives

  • Modern C++ (STL, RAII)
  • Concurrency & multithreading
  • Lock-free data structures
  • Sockets & network programming
  • Memory management
  • Performance optimization
02

Languages

fluent

  • C++
  • Rust
  • Go
  • Python
  • SQL
03

Compilers & Tooling

end-to-end toolchains

  • LLVM
  • Lexers / parsers
  • AST design
  • IR code generation
  • Language design
04

Data & Distributed Systems

at scale

  • Data pipelines & ETL
  • Distributed systems
  • Query engines (DataFusion)
  • Vector search (ChromaDB)
  • FTS5 / hybrid retrieval
05

Infrastructure & Web

to ship it

  • Docker / compose
  • Caddy
  • launchd orchestration
  • Next.js / React
  • OAuth
  • CI/CD
05About

The throughline

I'm a data engineer who spends his real attention one layer down — on the code that decides whether a system is fast, correct, and able to survive contention.

I've written a concurrent HTTP/1.1 server in C++ by hand, built a compiler with three of my own LLVM optimization passes, and implemented a lock-free split-ordered hash table in Go under a supervising professor. The throughline is the same: I want to understand systems at the level where the tradeoffs are real — memory ordering, cache behaviour, what the scheduler actually does.

It's the same instinct that pulls me toward low-latency and large-scale data infrastructure — domains where systems performance is the product, not a footnote. I send patches upstream — merged into Zed, SerenityOS and Godot, with more always in review — to keep that bar honest, and I train on timed competitive-programming contests: the closest proxy I've found to solving hard problems correctly and fast under pressure.

data engineer · low-latency systems bangalore · IST
Amogh Ramesh
amogh rameshc++ · rust · go
06Contact

Building something that needs the fast, correct layer?

I'm reachable directly, and I read every cold email.