Skip to content
AakashdeepSoftware EngineerTrading Systems & Backend Infrastructure

Aakashdeep — Software Engineer. The machinery behind the market.

I build order execution engines, market-making strategies and the fail-safes that let real money move without anyone losing sleep.

See the workRésumé
IST --:--:--
01Approach

How I think about systems

Three positions that decide most of the design work before any code is written.

Nobody sees the ledger.

A number changes on a screen. Underneath, one order has become two legs — one of them optimistic — and something has to guarantee they converge. That part has no interface, no screenshot, and no forgiveness.

Correct, then observable, then fast.

In that order, every time. A fast system you cannot observe is a system you cannot fix. And a system you cannot fix was never correct — it was lucky, and luck has a half-life.

Assume the retry.

Every message arrives twice eventually. Every process dies mid-write eventually. Designing for that up front costs a week; reconciling it afterwards costs a quarter. It is the difference between an incident and a log line.

02Experience

Where the work shipped

Two companies, three roles, and the specific things I owned in each. Numbers are the ones I can stand behind.

Nov 2025 — Present

CoinSwitch

SDE-1

Order execution, market making and the safety rails around real money.

01Decoupled order execution

~4.1K LOC · Postgres-backed e2e suite

Built the client leg of decoupled execution inside the crypto futures order engine — users are credited with instant synthetic fills while the exchange leg settles asynchronously. Idempotent fill events, double-credit-safe order-update routing, and a reconciler that nets in-flight legs.

  • Go
  • PostgreSQL
  • Idempotency

02Futures hedging strategies

4 of 6 strategies · ~39K LOC incl. tests

Sole author of four of the six production hedging strategies in a portfolio-protection service that shorts Bybit futures against user spot holdings. Confirmation-window state machines, market-order fallback when price moves against the hedge, and safety-gated auto-repair of live position drift.

  • Go
  • State machines
  • Bybit

03Cross-exchange market making

3 venues

Owned production tuning of the XEMM strategy on a Hummingbot fork spanning Binance, Bybit and KuCoin. Built a tick-size-aware quantization engine that widens profitability bands dynamically — eliminating false order cancellations caused by exchange price rounding.

  • Python
  • Hummingbot
  • Quantization

04Trading runtime re-architecture

Collapsed a one-pod-per-coin Kubernetes runtime into multi-coin pods using all-or-nothing Redis distributed-lock acquisition, with per-coin kill switches preserved. Cut per-coin infrastructure overhead without giving up isolation of failure.

  • Kubernetes
  • Redis
  • Distributed locks

05Risk & treasury automation

Built the risk service's data and reporting layer: restart-safe Redash-to-PostgreSQL PnL ingestion, automated daily and weekly PnL reports into Slack, broker-config CRUD APIs, and automatic top-up of exchange futures margin.

  • FastAPI
  • PostgreSQL
  • Automation

Jan 2025 — Oct 2025

Gameskraft

Software Engineer

Fraud prevention at play-time, and the secrets infrastructure underneath it.

01Denial rules

~9% fewer fraud incidents · WDPR 5.5 → 5.0

Designed and shipped Wi-Fi-based denial rules, later extended to multi-factor links — PIDI, L2 connections, Wi-Fi events — to stop linked or fraudulent players from being seated at the same table.

  • Java
  • Rules engine
  • Fraud

02Fraud detection accuracy

~5% higher detection accuracy

Introduced badDp and susDp gameplay-pattern checks ahead of the block decision, so genuine players stopped absorbing false positives.

  • Detection
  • Heuristics

03Secrets & config hardening

Stood up HashiCorp Vault on AWS end to end for org-wide secret management, migrating services off hard-coded and Zookeeper-held secrets. Replaced manual Zookeeper UI edits with Jenkins-driven scripts and JSON-based PR review — configuration became auditable.

  • HashiCorp Vault
  • AWS
  • Jenkins

04End-to-end service ownership

Owned services from HLD/LLD through implementation, testing, AWS deployment and monitoring on Grafana and CloudWatch — with Kafka-based event processing in the path.

  • System design
  • Kafka
  • Grafana

Jun 2024 — Aug 2024

Gameskraft

Software Engineer Intern

First contact with production fraud infrastructure.

01Rule configuration standardisation

Refactored fraud-detection rule configuration in Zookeeper into a centralised baseVariantConfig — structured arrays for monitoring and blocking modes, segregated by entry fee — then migrated every existing rule onto it.

  • Zookeeper
  • Refactor

Education

National Institute of Technology, Delhi

B.Tech, Electrical & Electronics Engineering

CGPA 7.52 / 10Graduated May 2025

Indus Public School, Jind

CBSE Class XII — PCM

94.6%2019 — 2020
03Systems

Anatomy of an order

A generalised picture of the class of system described above — deliberately not any one employer's architecture, and carrying no proprietary detail.

Scroll the diagram sideways →

  • Order flow
  • Control & telemetry
  • Hover or tab a component

Idle

One order enters, becomes two legs, and has to end up as one consistent balance. Everything on this diagram exists to make that true even when a venue is slow, a pod dies, or the same event arrives twice.

04Stack

The layers I work in

Grouped the way the systems are actually layered. Select a layer to see what it is built from.

Go and Python for anything that touches an exchange; Java where the JVM already lives.

  • Go
  • Python
  • Java
  • SQL
  • C++
  • TypeScript

Cross-cutting

Engineering

  • Distributed systems
  • System design (HLD / LLD)
  • Idempotency & reconciliation
  • Algorithmic trading
  • Data structures & algorithms
05Projects

Built from scratch

Three independent systems, each solving a problem I actually had. All source is public.
01Trading terminal2026

DMA Terminal

A self-hosted derivatives terminal where the exchange key never reaches the browser.

upstreamexchange1 pollshared samplered25519 · keys stay hereclientclientclientclientn clients → 1 upstream request
Fig. 01 — shared-poll fan-out

Problem

An exchange API key can move your entire balance. Every off-the-shelf terminal wants that key in the browser — and every tab you open hammers the same rate limit.

Approach

One FastAPI process holds the credentials, signs every upstream request server-side with Ed25519, and multiplexes a single poll out to every connected tab over WebSocket.

Result

Roughly 29K lines, 40+ REST endpoints and 346 tests, built solo in about seven weeks — with GitHub Actions running lint, tests and a money-math regression suite on every push.

Engineering decisions

01
Credentials stop at the server

Request signing happens in the backend. The browser receives data, never a key. Sessions are signed cookies with admin and viewer roles, one live session per role.

02
Three independent gates on every write

A session check, a constant-time trade token, and a typed confirmation. Fund transfers are idempotent and order timeouts are double-execution-safe. Ambiguous writes fail closed and land in a JSON audit trail.

03
O(1) upstream, N clients

A shared sampler polls the exchange once per interval and broadcasts. The tenth tab costs nothing upstream — the same feed drives live dashboards, a full-universe scanner and hysteresis-based risk alerting.

04
An LLM coach that cannot leak

Trade history syncs to MongoDB on a crash-safe loop with Telegram alerting. The coach talks to Claude, OpenAI or Gemini behind a field allowlist, so private position data never rides along.

Lines
~29K
Endpoints
40+
Tests
346
Solo build
7 wks
View source
  • Python
  • FastAPI
  • MongoDB
  • WebSockets
  • Ed25519
  • Vanilla JS
02Message broker2026

Streamix

Kafka's contract — topics, partitions, consumer groups, offsets — rebuilt from first principles over plain REST.

topic · ordersappend →p016 mibp116 mibp216 mibretention prunes segmentsconsumer offset
Fig. 02 — partitioned append-only log

Problem

Kafka's programming model is what most services actually need. Kafka's operational weight — brokers, a membership protocol, a binary wire format — is what most services cannot justify.

Approach

A Spring Boot broker that keeps the semantics and drops the machinery: HTTP and JSON on the wire, append-only segmented logs on local disk, and a coordinator that performs real consumer-group rebalancing.

Result

Two Maven modules — broker and a thin Java client — 64 classes and 75 tests, an OpenAPI surface, and a multi-stage Docker image with an actuator healthcheck. Around twenty tuning properties ship with it.

Engineering decisions

01
Segmented append-only log

Each partition is a run of JSON-lines segments rolled at 16 MiB, with a separate offsets journal. Retention prunes whole segments, so reclaiming disk is a file delete rather than a compaction pass.

02
At-least-once, ordered per partition

Offsets are committed by the consumer, never implicitly by the broker. Redelivery is the stated contract; per-partition ordering is the guarantee that makes that contract workable.

03
Rebalancing without a wire protocol

A group coordinator tracks consumer sessions and reassigns partitions on join, leave and expiry — over the same REST surface. A consumer stays a client instead of becoming a participant in a membership protocol.

04
Long polling over streaming

Consumers block server-side until data arrives or a deadline passes. No persistent connections and no backpressure protocol — and it survives any proxy in between.

Classes
64
Tests
75
Partitions / topic
64
Segment roll
16 MiB
View source
  • Java 17
  • Spring Boot
  • Maven
  • OpenAPI
  • Docker
03Rules engine2026

Alerts Manager

A market-watching rules engine that evaluates continuously and speaks only when something actually happened.

evaluationtick loopcandle loopconditions8 types · plugincooldowndedup gatetelegramrsi · ema · smamacd · bollingerhovering the threshold fires once, not two hundred times
Fig. 03 — evaluation pipeline

Problem

Market alerting is easy to build badly. A naive loop either misses the crossing entirely, or fires the same alert two hundred times while price hovers on the threshold.

Approach

Two independent evaluation loops — one on ticks, one on candle closes — feeding a pluggable condition registry, with cooldown and dedup sitting between an evaluation and a notification.

Result

Eight alert condition types across 13 endpoints, async SQLAlchemy over SQLite by default and PostgreSQL when you want it, delivered to Telegram. Multi-stage Docker build with a compose healthcheck and a named volume.

Engineering decisions

01
Conditions are plugins, not branches

A registry maps condition types to evaluators across price, indicator and volume families. Adding the eighth alert type touches one file instead of the engine.

02
Indicators computed in process

RSI, EMA, SMA, MACD and Bollinger bands are hand-rolled against the candle loop. No dataframe library in the hot path and no numerical dependency to pin forever.

03
Cooldown and dedup as first-class state

A trigger writes an event, and that event decides whether the next evaluation is permitted to speak. Threshold hovering produces one alert rather than a stream of them.

04
One process, two faces

The same FastAPI app serves the REST API, the built React SPA and the background engine. One container, one healthcheck, one thing to deploy.

Condition types
8
Endpoints
13
Eval loops
2
Indicators
5
View source
  • Python
  • FastAPI
  • SQLAlchemy
  • PostgreSQL
  • React
  • TypeScript
06Console

Ask it directly

Everything on this page, reachable as commands. Tab completes, arrows walk history.
aakashdeep — console
07Contact

Let's build something that holds.

aakashdeepkundu@gmail.com
SRCGitHub
NETLinkedIn
ALGOLeetCode
DOCRésumé

AAKASHDEEP

Make it correct · make it observable · then make it fast

Software Engineer · CoinSwitch

India · IST (UTC+05:30)

Next.js · React Three Fiber · Motion · Lenis

No trackers, no cookies

© 2026

Aakashdeep — bootIndia · IST (UTC+05:30)

AAKASHDEEP

resolving typefaces000