most of what's on this page, I didn't know how to build when I started.
I'm dharmik, a final-year software engineering student in Mumbai. I write Go(along with other stuff) and I like backend systems.
For each thing I built, I kept notes on where I got stuck, what I weighed, what I chose, and what I'd change now. Those notes are below.
Decisions
Problems I didn't know how to solve when I started.
02 · strata ·
Where should the information for skipping files live?
the problem
A search should open only the log files that can hold the answer. Knowing which ones means storing each file's time range and word summary somewhere, and reading it costs time on every search.
what I considered
Keep the summary inside each file and read just that part from storage. A separate database like Postgres. A SQLite file inside the server.
what I picked
A SQLite file with one row per log file: time range, size, and its bloom filter. A search reads it first and opens only what it can't rule out.
what I'd change
On 196 files, a one-hour search for a common word opened 2 or 3 files in 55 ms. Across all time it opened 171 in 2.1 s. The cost: one file the server can't lose.
What should happen when two devices edit the same file?
the problem
Two devices can edit the same file while one is offline. If the last upload just wins, one of those edits disappears and nobody is told.
what I considered
Last upload wins, locking files, merging edits automatically, or keeping both versions.
what I picked
Keep both. The server turns away any upload based on an old version, and the device saves its own edit as a conflicted copy next to the original.
what I'd change
My first prototype let the server pick the version, so it never caught this. There's still a tiny window where a save during a download can get overwritten.
A log search engine that skips the stored files a search can't need. In progress.
go grpc sqlite s3 docker
Experience
May 2026 - July 2026
AI Engineering Intern, Yes Bank Limited
Moved a document-extraction step that blocked users for 5+ seconds into a fault-tolerant background job queue with status tracking. Built on the service's existing PostgreSQL: an internal, low-load tool didn't need Redis, RabbitMQ or Kafka.
Apr 2026 - May 2026
Software Engineering Intern (Backend), AutoWisdom
Added tight IP-based rate limits (3/min, 5/hour, 12/day) to a public AI endpoint with no sign-in. Real users take longer than that to read a report, so the limits only stop abuse.
Things I don't know yet
What I'm working through right now, and how.
CPU caches and memory
reading CS:APP and Drepper's memory paper while building a lock-free ring buffer in C++
Atomics and memory ordering
working through Preshing's posts to justify every acquire and release in that buffer
Measuring latency
learning to benchmark honestly before I publish any p99 numbers
Storage engines and search indexes
next: Kleppmann and Introduction to Information Retrieval, for my log search engine