Skip to main content

Pro Algo Trading | AlgoKing

Recent

dynamic position sizing - kelly criterion meets regime detection
one of the dumbest things i did in 2023 was running fixed position sizes. every trade was the same size regardless of conviction, volatility, or recent performance. looking back it’s obvious why i hemorrhaged $180k - i was sizing up the same during high-vol crashes as during calm trending markets.
monitoring and alerting for algo infrastructure - grafana + prometheus setup
realized last month that i had a massive blind spot in my infrastructure: monitoring. my algos were running 24/7 but i had no idea if they were running WELL until i checked PnL at end of day. that’s like driving with your eyes closed and checking if you crashed when you stop.
exchange connectivity layer - handling binance, kraken, and coinbase in one abstraction
one of the most annoying parts of crypto algo trading is that every exchange has a different API. different auth schemes, different rate limits, different order types, different error codes. writing strategy logic for each exchange separately is a nightmare and a maintenance disaster.
saturday - apartment shit and almost burning the kitchen down
a has been on this kick where she wants me to learn to cook. not like ramen-and-eggs level (i can manage that without supervision). she means actual cooking. from recipes. with ingredients that expire.
async signal generation - why your pipeline is probably too slow
been refactoring my signal generation pipeline for the last 2 weeks. old version was synchronous - fetch data, compute indicators, generate signal, repeat. worked fine when i was running 3 strategies. now i’m running 11 and the whole thing was choking.
redis for market data - why i ditched postgres
moved all my real-time market data from postgres to redis about 8 weeks ago. latency dropped from ~15ms to sub-millisecond. should’ve done this way earlier. the postgres problem # when i first built my algo infrastructure i stored everything in postgres because that’s what i knew. tick data, order book snapshots, greeks, everything went into timescaledb (postgres extension for time-series).
slippage models - making backtests actually realistic
been thinking about slippage modeling a lot lately. most backtest frameworks have absolute dogshit slippage assumptions - either zero (lmao) or some fixed percentage that doesn’t scale with order size or volatility.
adaptive stop losses - why fixed stops are leaving money on the table
2:30am wednesday. been refactoring my exit logic all week. fixed stop losses are lazy. there I said it. the problem with fixed stops # “just use a 2% stop loss.”
saturday - valentine's planning and dr R wants details
2am saturday. A. fell asleep on the couch watching some cooking show. I carried her to bed. she mumbled “you’re warm” and passed out. now I’m sitting in the dark thinking about valentine’s day.
monte carlo backtesting - why single backtest runs lie to you
2:30am wednesday. ran a single backtest last week. looked incredible. sharpe of 2.4. max drawdown 8%. then I ran 10,000 of them. reality check. the problem with one backtest # you run a backtest. it returns +22% over 2 years.