A/B
Index
RésuméContact

Computer science and software engineering, London

I build software for quantitative research, portfolio tracking, and data-heavy problems.

I’m a computer science student focused on backend and platform engineering. I also work on embedded systems and machine-learning experiments.

Open the live app Email me
Price-history query latency, before and after continuous aggregatesA logarithmic bar chart comparing a measured price-history query at 347 milliseconds before optimisation and 1.05 milliseconds after, a 330-fold reduction over 1.55 million rows.FIG. 01 / PRICE-HISTORY QUERY, MEASURED347 ms1.05 ms330×FASTER1.55M ROWS / 6 SYMBOLS / 546 CHART POINTS RETURNED IDENTICALLYPrice-history query latency, before and after continuous aggregatesA logarithmic bar chart comparing a measured price-history query at 347 milliseconds before optimisation and 1.05 milliseconds after, a 330-fold reduction over 1.55 million rows.PRICE-HISTORY QUERY, MEASUREDBEFORE347 msAFTER1.05 ms330× FASTER / 546 CHART POINTS IDENTICAL
THE PORTFOLIO APP / CONTINUOUS AGGREGATESMEASURED AUGUST 2026

Selected work

Four projects: a portfolio app, a quantitative research tool, a poker engine, and a neural pitch shifter.

01 / The Portfolio App

A portfolio tracker built across four backend services.

A working portfolio tracker for virtual accounts and shared households. It records transactions, calculates holdings, valuation, P&L and time-weighted returns, and tracks allocation drift using live prices.

Status
Functional staging
Date
August 2026
Role
Creator
services
4 deployed backend services
contracts
REST, gRPC, codegen
platform
k3s, Helm, Terraform
The Portfolio App dashboard showing position value, all-time return, a performance chart, and total return, day's change, cost basis and benchmark tiles.
Public staging deploymentLive product, August 2026

Four measured results from the current build.

  1. Query path

    347 ms1.05 ms

    330× faster

    TimescaleDB continuous aggregates cut a measured six-symbol, 1.55-million-row price-history query while returning all 546 chart points identically.

  2. Idle cost

    3.1M writes0 writes

    per month, idle

    Quote caching moved from supply-pushed polling to demand-filled write-back, so staging stops writing to Redis when nobody is reading.

  3. Quote fan-out

    2H calls2 commands

    H = holdings

    A sparse GetQuotes gRPC batch resolves up to 256 symbols through one MGET and one set-based Timescale query instead of one call per holding.

  4. Token rotation

    6 commands1 command

    6× fewer

    An atomic Lua script replaced six refresh-token mint operations, taking full issue and rotation flows from 8/9 commands down to 3/4.

Technical details
  1. BOUNDARIES

    FastAPI handles the main product workflows. Rust handles quote ingestion and calculation-heavy work. The public API uses OpenAPI; services communicate over gRPC using protobuf.

  2. CORRECTNESS

    Transactions are the source of truth. Positions and daily NAV can be rebuilt from the ledger, and a dirty watermark queues recalculation when an older transaction changes.

  3. SECURITY

    The gateway signs tokens with Ed25519. Other services validate them from the public JWKS and receive audience-scoped credentials that expire after 60 seconds.

  4. DELIVERY

    Terraform provisions Hetzner and Cloudflare. Helm deploys the services to k3s after database migrations, and Playwright checks the deployed commit before it is marked ready on staging.

The Portfolio App staging architectureA SvelteKit web application reaches FastAPI services over public REST; portfolio, pricing, and calculation services communicate through generated gRPC contracts and store state in Neon Postgres, Upstash Redis, TimescaleDB, and Cloudflare R2 on a Terraform-provisioned k3s platform.STAGING / CONTRACT-DRIVEN SERVICE GRAPHSVELTEKITWEB / BFFAPI GATEWAYFASTAPI / RESTPORTFOLIOFASTAPI / LEDGERPRICINGRUST / TonicCALCRUST / PolarsHTTPSRESTgRPCgRPCPUBLIC REST OVER HTTPSINTERNAL gRPC, GENERATED FROM PROTOBUFNEONPOSTGRESUPSTASHREDISTIMESCALEDBPRICE HISTORYR2BACKUPSTERRAFORM → HETZNER → k3s → HELMCLOUDFLARE EDGE / DOPPLER SECRETSThe Portfolio App staging architectureA SvelteKit web app calls a FastAPI gateway over public REST. The gateway reaches the portfolio, pricing and calculation services over internal gRPC, and those services store state in Postgres, Redis, TimescaleDB and R2.CONTRACT-DRIVEN SERVICE GRAPH
Open staging app

From tracking value to explaining risk and tax.

  1. Statistics and risk

    I’m adding rolling volatility, drawdown, Sharpe and Sortino ratios, benchmark beta, historical VaR, correlations, Monte Carlo projections, and factor exposure. Each calculation will be checked against reference fixtures before it appears in the Risk interface.

  2. UK capital gains

    A Rust tax service will implement HMRC same-day matching, the 30-day bed-and-breakfast rule, and Section 104 pooling, with worked-example and property tests plus tax-year reports exported to R2.

  3. Production connections

    The next step after staging is direct Trading 212 and IBKR sync, production OAuth, and clearer failure states.

02 / OpenQuant

Run and compare reproducible backtests from Python strategies.

An early alpha for running Python strategies and inspecting the results. Each run records its code, parameters, data version, engine version, and random seed. The current build has completed a 190-trial grid search.

Status
Pre-release alpha
Date
August 2026
Role
Creator, full-stack engineer
data
4 sources
portfolio
Up to 50 symbols
sweeps
190 verified, 10k limit
Result
190 of 190 sweep trials completed
OpenQuant light-theme market research workspace showing an AAPL candlestick chart, volume, data controls, and symbol panel.
Market research workspaceReal product capture, August 2026
Product screens4 interface captures
OpenQuant Python strategy editor displaying a MACD research script.
Script editor
OpenQuant backtest results showing headline metrics, price signals, equity, and drawdown charts.
Backtest results
OpenQuant optimization workspace showing a completed 190-of-190 grid search and parameter heatmap.
Parameter sweep
OpenQuant multi-asset portfolio results showing holdings, attribution, weights, and risk metrics.
Portfolio results
Technical details
  1. DATA

    Research can use Yahoo Finance, Binance, Twelve Data or local CSV files, with portfolios of up to 50 symbols.

  2. RUNS

    Grid and seeded-random searches support up to 10,000 trials. The run shown completed 190. Strategy code runs without network access and under process resource limits.

OpenQuant research architecturePython indicators and market data flow through parameter sweeps and reproducible backtests into portfolio results.PYTHON INDICATOR / MARKET SERIESREPRODUCIBLE RUNRESEARCH EVENTPYTHON SCRIPTPARAMETER SWEEPBACKTESTPORTFOLIO
View repository Watch video showcase

03 / Poker TUI

A Texas Hold’em engine and terminal interface written in Rust.

A Rust terminal game built around a pure poker engine, local bots, live equity estimates, and a networked client/server mode.

Status
Complete and maintained
Date
2025
Role
Creator, Rust engineer
system
Game engine, TUI
focus
State and probability
stack
Rust, Ratatui
Result
Includes the game engine, terminal UI, bots, equity estimates and client/server play. The image below is an illustration, not a product screenshot.
Poker TUI technical illustrationAn illustrative Texas Hold'em table state with four seats, five community cards, action options, and an equity rail.HAND STATE / 17A♠10♦7♣K♥POT / 1,24001BOT / 0202BOT / 0303YOU / 0104BOT / 04EQUITYILLUSTRATIVE STATEFOLDCALLRAISE →CORENETSERVERCLIENT
Rules, state, and probabilityIllustrative hand state
Technical details
  1. CORE

    A pure poker engine keeps game rules separate from the terminal interface.

  2. STATE

    Bots choose from the legal actions for the current hand, while the interface updates the equity estimate as cards are dealt.

View repository

04 / Neural Pitch Shifter

An experiment in shifting pitch without losing timbre.

The pipeline uses a conditional U-Net to predict a pitch-shifted mel-spectrogram, then HiFi-GAN turns it back into audio. Demucs can separate vocals before processing.

Status
Experimental, no validated result yet
Date
August 2026
Role
Creator, ML engineer
system
Audio pipeline
focus
Pitch and timbre
stack
PyTorch, DSP
Result
The pipeline is implemented, but training and model comparisons are still in progress. The diagram shows the intended signal flow.
Neural Pitch Shifter technical illustrationAn audio waveform and mel-spectrogram pipeline showing conditional pitch transformation and resynthesis.AUDIO / CONDITIONAL TRANSFORMATIONINPUT WAVEFORM22.05 KHZTARGET MEL-SPECTROGRAMF0 + SHIFTPITCH U-NETHI-FI GANAUDIO
Conditional audio transformationIllustrative signal pipeline
Technical details
  1. MODEL

    A pitch-conditioned U-Net predicts the target mel-spectrogram.

  2. OUTPUT

    HiFi-GAN resynthesizes audio; Demucs can isolate and remix vocals.

Pitch U-Net model architectureFour residual encoder blocks downsample the mel and F0 features into an attention bottleneck. A mirrored decoder upsamples through four F0-gated skip connections, while the semitone shift conditions every residual block through FiLM.MODEL / PITCH U-NET STRUCTURE64 CH80 × TE1128 CH40 × T/2E2256 CH20 × T/4E3384 CH10 × T/8E4384 CH10 × T/8D4256 CH20 × T/4D3128 CH40 × T/2D264 CH80 × TD1384 CH5 × T/16ATTN BOTTLENECKMEL + F0Δ MELF0-GATED SKIP CONNECTIONSSHIFT (ST)MLP → 64-D CONDITION → FiLM IN EVERY RESBLOCK4 × DOWNSAMPLE 2 → SELF-ATTENTION → 4 × UPSAMPLE 2Pitch U-Net model architecture, simplifiedInput passes through four downsampling blocks, an attention bottleneck, and four upsampling blocks to the output. One representative F0-gated skip connection links the downsampling and upsampling paths.MODEL / PITCH U-NET
View repository

Experience

  1. Data Science Intern

    Dr. Koffer New York, Moscow

    Built forecasting and allocation tools for the logistics team, contributing to a reported 15% reduction in costs. I also built a Telegram bot that gave managers up-to-date product metrics and charts.

KCL Racing, Formula Student

Writing firmware for KCL Racing’s steering-wheel electronics.

I programmed STM32 firmware in low-level C for a display embedded in the steering wheel, while working on reliable fuel-level tracking and the control logic around acceleration during electronic downshifts.

The firmware depended on decisions from the engine and powertrain teams. I turned those discussions into timing, sensor, actuator, and failure-state requirements, then fitted the work into a deterministic loop on one microcontroller core.

KCL Racing steering-wheel electronics blueprintAn STM32 firmware loop connects steering-wheel controls, fuel and drivetrain signals, an embedded driver display, and electronic downshift actuation, with reliability constraints around every path.KCL RACING / STEERING ELECTRONICS / SYSTEM STUDYDRIVER DISPLAYGEAR 4−+STM32LOW-LEVEL C / 1 COREFUEL SIGNALFILTER / ESTIMATEDRIVER INPUTSPADDLES / STATEDISPLAYFAST FEEDBACKDOWNSHIFTACTUATION LOGICBOUNDED LOOPSENSOR NOISEFAIL-SAFE OUTPUTSWATCHDOG / RECOVERYKCL Racing steering-wheel electronics, simplifiedFuel signal and driver paddle inputs feed an STM32 running a bounded loop in low-level C, which drives the steering-wheel display and the electronic downshift actuation.STEERING ELECTRONICS / SYSTEM STUDYFUEL SIGNALFILTER, ESTIMATEDRIVER INPUTSPADDLES, STATESTM32LOW-LEVEL C, 1 COREDRIVER DISPLAYFAST FEEDBACKDOWNSHIFTACTUATION LOGICGEAR 4BOUNDED LOOPOne core, fixed budgetSENSOR NOISEFilter and sanity-checkFAIL-SAFE OUTPUTSKnown state on faultWATCHDOGRecover without a reset
Steering electronics, functional system blueprint
  1. Design for physical uncertainty

    Fuel moves under braking and cornering; readings need filtering, sanity checks, and behaviour that remains useful when the signal is imperfect.

  2. Make time and failure explicit

    On one core, every task competes for a bounded budget. Display refreshes and control paths must be scheduled deliberately, with safe outputs and recovery treated as part of the design.

  3. Agree on boundaries first

    Electronic shifting crosses firmware, mechanical behaviour, engine response, and driver expectations. We had to agree on those boundaries before encoding them.

Reliability came from lots of small decisions about timing, bad sensor data, safe outputs, and recovery.

Education

  1. BSc Computer Science

    King’s College London

    In progress, graduating 2027. Coursework covers systems, machine learning, and optimisation.

  2. Foundation in Mathematics and Computer Science

    King’s College London

    83% overall. 89% in computer science, 86% in mathematics for natural sciences.

Systems

  • Operating systems and concurrency
  • Computer systems
  • Compilers and formal languages
  • Databases

Theory and maths

  • Data structures
  • Optimization methods
  • Cryptography
  • Signals and systems

Applied AI

  • Artificial intelligence
  • Machine learning
  • Data science
  • Robotics

Additional

  • King’s Quant Academy
  • Associate Data Scientist in Python, DataCamp, June 2024

Technical profile

The tools and engineering areas I’ve worked with across these projects.

Backend

  • FastAPI and RustProduct workflows, calculation services
  • PostgreSQLTransactions, rebuildable views
  • OpenAPI and protobufREST, gRPC, generated clients
  • AuthenticationEd25519, JWKS, scoped JWTs

Reliability and testing

  • Reproducible runsCode, data, engine, seed
  • Isolated workersNetwork blocks, resource limits
  • RecoveryDirty watermarks, retryable rebuilds
  • Deployment checksCI, migrations, Playwright

Performance

  • Database queries347 ms to 1.05 ms measured
  • Batching and cachingSparse MGET, write-back quotes
  • Atomic updatesLua-backed token rotation
  • Infrastructurek3s, Helm, Terraform

Quantitative software

  • Portfolio accountingTransactions, holdings, TWR
  • BacktestingSeeded runs, parameter sweeps
  • Market dataMultiple sources, live updates
  • Poker engineEquity, legal actions

Embedded and ML

  • STM32 firmwareBounded loops, sensors, control
  • Signal processingMel spectrograms, F0
  • Audio modelsU-Net, FiLM, training
  • Audio resynthesisHiFi-GAN, Demucs

Languages spoken

  • EnglishFluent
  • RussianNative
  • SpanishProfessional

What I’m working on now.

Current builds and experiments.

  1. Building

    Working on The Portfolio App

    I’m adding risk and tax calculations, broker connections and multilingual support. Mobile apps are planned next.

  2. Releasing

    Preparing OpenQuant for an alpha release

    I moved backtest snapshots to persistent storage and finished work on CI, runtime limits and release automation.

  3. Researching

    Can pitch shifting preserve timbre?

    I’m comparing a pitch-conditioned U-Net with an ungated version on speech and music, then testing whether a transformer preserves formants more accurately.

How I work.

I usually begin by mapping the states, constraints, and failure cases. Then I build enough instrumentation to check whether the design works in practice. I’ve used that process in portfolio software, backtesting tools, embedded firmware, and audio ML.

  1. Understand the problem

    Learn the rules and failure cases before settling on an API or data model.

  2. Make it inspectable

    Add logs, metrics, and interfaces that show what the system is doing.

  3. Measure, then refine

    Use the results to decide what to simplify or optimise.

Iterative engineering loopA circular process connects understanding, structuring, measuring, and refining a system.01020304UNDERSTANDSTRUCTUREMEASUREREFINE
ENGINEERING LOOP / EVIDENCE BEFORE ORNAMENT

Get in touch.

I’m looking for software engineering roles, especially in backend, quantitative, or data-heavy teams.

Email me

aleksandr@babarika.devLondon, United Kingdom