Prateek Sharma — Backend & Systems Engineer on Prateek Sharma

Database Internals

Tue, 01 Sep 2026 00:00:00 +0000

TODO: Add review / notes once read.

Designing Data-Intensive Applications

Tue, 01 Sep 2026 00:00:00 +0000

TODO: Add review / notes once read.

Release It!

Tue, 01 Sep 2026 00:00:00 +0000

TODO: Add review / notes once read.

The Go Programming Language

Tue, 01 Sep 2026 00:00:00 +0000

TODO: Add review / notes once read.

Understanding Distributed Systems

Tue, 01 Sep 2026 00:00:00 +0000

TODO: Add review / notes once read.

Whisper's turbo model beat large on noisy audio, in practice

Mon, 31 Aug 2026 00:00:00 +0000

Building the Video Translator , the assumption going in was that OpenAI Whisper’s larger model would transcribe more accurately. In practice, on clips with loud background music, the turbo model did noticeably better than large — it seems to tolerate messy audio better rather than just being a faster, lower-quality option. Separating vocals from background music first (with demucs) didn’t help as much as expected either; Whisper handled the mixed track better on its own. Worth trying turbo first rather than assuming bigger is more accurate.

Composite index column order should match the query, not the schema

Sun, 30 Aug 2026 00:00:00 +0000

In the TTS Study Assistant notes table, queries filter by user_id always and domain often, so the index is declared in that order:

CREATE INDEX idx_uid_did ON notes(user_id, domain);

A composite index is only fully useful as a left-prefix: this index serves WHERE user_id = ? and WHERE user_id = ? AND domain = ?, but not WHERE domain = ? alone. The rule of thumb is to order columns by how the queries actually filter — most selective / most-always-present first — not by declaration order in the table, and not alphabetically.

Daemon threads for WebSocket keepalives

Sat, 29 Aug 2026 00:00:00 +0000

A WebSocket connection that needs periodic pings to stay open shouldn’t run that ping loop on a plain, non-daemon thread. In the WazirX Java connector , the ping thread is started onOpen and marked setDaemon(true) before starting it:

pingThread = new Thread(new PingMessage(this));
pingThread.setDaemon(true);
pingThread.start();

A non-daemon thread keeps the JVM alive until it finishes. If a caller opens a socket, forgets to close it, and the rest of the application shuts down, a non-daemon ping thread will keep the process running indefinitely. A daemon thread just gets killed when everything else is done — which is the right default for background keepalive work that isn’t itself the point of the program.

Give callers two error types, one extending the other

Fri, 28 Aug 2026 00:00:00 +0000

In the WazirX Java connector I split errors into two:

WazirxClientException — the caller made a mistake the caller can fix: a bad side value, a missing required field. Thrown before a request is even sent.
WazirxApiException — something went wrong once the request left the process: a network failure, a non-2xx response.

WazirxClientException extends WazirxApiException. That one line is the whole design. A caller who only cares “did this work?” catches the parent. A caller who wants to retry network failures but fail fast on their own bad input catches both separately. Nobody is forced into a giant catch (Exception e) that swallows bugs, and nobody has to try/catch five specific types at every call site.

Two-sided membership needs one lock, not two

Thu, 27 Aug 2026 00:00:00 +0000

Goroomlib models a relationship that points both ways: a Room holds a map of its users, and each User holds a list of the rooms it’s in. That redundancy is deliberate — both lookups need to be O(1) — but it’s also the whole bug surface.

The first version

AddUserToRoom did the obvious thing:

func (s *RoomService) AddUserToRoom(roomName string, user *User) {
    room := s.rooms[roomName]

    room.mu.Lock()
    room.users[user.ID] = user
    room.mu.Unlock()

    user.mu.Lock()
    user.joinedRooms = append(user.joinedRooms, roomName)
    user.mu.Unlock()
}

Each side is individually locked, so go vet and the race detector on a simple test are both happy. But there’s a window between the two critical sections where the room says “user is here” and the user says “I’m not in that room.” Anything that reads both — say, a disconnect handler that walks user.joinedRooms to remove the user from each — can run in that window and leak the membership.

Generic returns can be the right call for a library you maintain alone

Wed, 26 Aug 2026 00:00:00 +0000

The standard advice for a client library is: give callers typed responses. client.Ticker(...) (*Ticker, error), not (any, error). I went the other way in my WazirX Go connector and I still think it was right for that library.

The upstream API’s response shapes move around — objects that become arrays, fields that appear and vanish across endpoints. With ~25 endpoints and one maintainer (me, in spare hours), typed structs would mean 25 things to keep in sync with an API I don’t control and can’t see changes to until they ship. The generic return pushed that cost to the call site, where the caller already knows which two fields they want and can assert for them.

Endpoint maps over hand-rolled methods

Tue, 25 Aug 2026 00:00:00 +0000

I’ve now written two client libraries for the same exchange API — one in Go , one in Java — and the thing I’d keep from both is the same: don’t write a method per endpoint. Describe the endpoints as data and dispatch through one function.

The shape of the problem

The API has roughly two dozen endpoints. They differ in four ways:

HTTP verb (GET, POST, DELETE)
path
whether the request must be signed
the response body

Everything else — building query params, adding a signature, choosing the verb handler, parsing the response — is identical. Writing a hand-rolled method per endpoint means writing that identical body 25 times, and then maintaining 25 copies of it when the signing scheme or the base URL handling changes.

Goroomlib

Sun, 23 Aug 2026 00:00:00 +0000

Across the poker platforms I’ve worked on at Adda52 and Mind Sports League, one shape kept showing up: users joining a table, leaving it, sending messages to everyone at it, and the server keeping track of who’s where. Every time I touched a new real-time feature, I ended up rewriting the same User and Room bookkeeping from scratch. I wanted to pull that pattern out once, get it right, and stop reimplementing it.

Tidylnk

Sun, 23 Aug 2026 00:00:00 +0000

Tidylnk is a URL shortener I built to have a simple, self-hosted alternative to the usual third-party link shorteners, with an admin panel to manage and track links.

Tech stack

Backend — Go, serving the redirect and link-management APIs.
Frontend — a React admin panel for creating, organizing, and tracking shortened links.
Storage — PostgreSQL as the primary datastore for link records, with Redis on the redirect hot path for fast lookups.
Deployment — backend and database containerized with Docker and deployed on Railway.

Why I built it

I wanted a link shortener I fully controlled — no reliance on a third party’s uptime, rate limits, or analytics restrictions — and a project to exercise Go and Redis together on a workload where caching genuinely matters: redirect latency.

WazirX Go Connector

Sun, 23 Aug 2026 00:00:00 +0000

WazirX is one of India’s largest crypto exchanges, and while its REST API is well documented, it doesn’t ship an official Go client. I wanted to poke at their API for a side project and didn’t want to hand-roll request signing and endpoint plumbing every time, so I built wazirx-connector-go and open-sourced it once it was in decent shape.

Avoiding ~25 near-identical methods

The exchange exposes close to two dozen endpoints — tickers, order book depth, order placement, withdrawals, sub-account transfers, and so on. Writing a hand-rolled method for each one would have meant the same boilerplate repeated two dozen times: build params, sign if needed, pick GET/POST/DELETE, hit the URL, parse the response.

WazirX Java Connector

Sun, 23 Aug 2026 00:00:00 +0000

After building the Go connector for WazirX, I wanted the same thing on the JVM — but WazirX doesn’t publish an official Java client at all, REST or WebSocket. The REST half was a fairly direct port of what I’d already learned building the Go client. The WebSocket half turned out to be its own project.

Letting callers choose their failure granularity

For errors, I didn’t want every caller forced into one giant catch-all exception, but I also didn’t want to force a try/catch at every single call site. I split errors into two, with one extending the other:

CoinTracker

Mon, 01 Sep 2025 00:00:00 +0000

CoinTracker is a crypto portfolio and tax platform. I worked on the ingestion and reconciliation side: getting on-chain data into the system correctly, and keeping wallet balances consistent across chains.

Engineering areas

Blockchain integrations

Integrated Cardano and Stellar, reading on-chain data from Snowflake for balance reconciliation, transaction parsing, and portfolio tracking.
Onboarded Akash and Axelar (cross-chain), plus Bitcoin Ordinals, Inscriptions, BRC-20, and Runes via the Ordiscan API.
Worked behind a unified blockchain abstraction so each new chain was a smaller, more predictable piece of work than the last.

Fault-tolerant wallet sync

Wrote the business logic behind Temporal workers for wallet-sync workflows: idempotent, retry-safe, and consistent across chains.
Built reconciliation pipelines and validation checks so cross-chain data disagreements surface as failures rather than silently wrong balances.

Data tooling

Built and consumed Flask REST APIs and CLI scripts for ingestion, validation, and reconciliation.
Used pytest and mypy to keep correctness and type safety enforced in CI.
Adopted Claude Code as an agentic assistant for feature work, debugging, and issue resolution.

Stack

Python · Flask · Temporal · Snowflake · pytest · mypy

Audio Cloning

Mon, 23 Jun 2025 00:00:00 +0000

This is an extension of the Video Translator tool that generates cloned audio for short subtitles, improving the quality of the dubbed output. It uses OpenVoice and MeloTTS to clone the original speaker’s voice.

Challenges

Library compatibility. The libraries weren’t functional on Python 3.12, which I was using — they worked on 3.10. So the TTS stage couldn’t live in the same script as the rest of the pipeline.
Short subtitles. The libraries needed a longer sample to clone a voice well, and very short lines (hello, hi, bye) errored out.

What I changed in the fork

openvoice/se_extractor.py had a check that discarded audio segments shorter than 1.5 seconds. Words like hello fall under that. I relaxed the check to allow segments down to ~0.5 seconds, and added a skip for lines too short to process.
Added melo-tts to requirements.txt (the docs mention it but don’t pin it).
Added a driver script that points at a video-translator output folder and runs cloning across every generated audio file.
Patched the library to run on CPU for Apple M1.

The fork is at github.com/pratts/OpenVoice ; test1.py runs the cloning over the translator’s output.

Video Translator

Mon, 23 Jun 2025 00:00:00 +0000

I always wanted to watch Japanese anime and other foreign-language films in English without living in the subtitles. During a break I decided to see how far open-source models could get me, and built a script that:

Extracts the background audio from the video.
Transcribes it to a subtitle file in the original language.
Translates each subtitle to English.
Converts the translated subtitles to audio.
Merges the translated audio with the background track.
Muxes the final audio back into the video.

I wanted to lean on open-source tooling and minimize paid services:

Patched OpenVoice for short-clip cloning and CPU inference

Fri, 20 Jun 2025 00:00:00 +0000

While building the Audio Cloning stage of my video-translator pipeline, I hit two blockers in OpenVoice :

openvoice/se_extractor.py discarded audio segments shorter than 1.5 seconds, which meant short subtitle lines (hello, hi, bye) couldn’t be cloned at all. I relaxed the threshold to ~0.5 seconds and added an explicit skip for lines too short to process.
The library assumed a CUDA GPU. I patched it to run on CPU so it worked on Apple M1.

The changes live in my fork at github.com/pratts/OpenVoice . They were scoped to my use case and haven’t been proposed upstream.