2:30 AM monday. week one of what i’m calling “the post-tariff-chaos era” starts in a few hours.
last week was one of those that splits into a clear before and after. monday and tuesday felt like freefall — VIX went from 20 to 32 in about 36 hours, SPX dropped hard, options spreads blew out 3-4x, and my event risk throttle (which I built the week prior and wrote about here) was earning every line of code it took to build. then wednesday happened. whoever made the tariff pause call did it at 1:07 PM eastern and watching the S&P rip 8% in ninety minutes while running algorithms was… a lot.
i’m not writing about the news. the news was the news. i’m writing about what the data actually showed — signal quality, execution behavior, infrastructure load, what broke, what held. post-mortem mode.
the signal picture #
my signals degraded before my positions did. that’s the thing nobody talks about in algo trading — you can survive the position stress, but if your signals are garbage, every decision downstream is garbage too.
SPX premium selling uses IV rank as a core input. normal conditions: IV rank sits around 20-35%, strategies enter incrementally, theta collects. monday morning of last week, IV rank hit 82% in pre-market and was moving fast enough that my 15-minute recalculation cadence was stale by the time each cycle ran. i was using a snapshot of IV rank that was already 10+ minutes old in conditions where the number was moving 3-4 percentage points per cycle.
this created a specific failure mode: my entry signals were suggesting “elevated vol = better premium, conditions favorable for new positions” while simultaneously my existing positions were getting hammered by the very vol spike causing those “good” signals. the logic was technically correct in isolation. in practice, it was noise.
the event risk throttle blocked new entries correctly — my VIX > 25 threshold triggered, max position size dropped to 40% (even lower than the week before), new entries suspended. but the signal quality problem was still there. i need faster IV recalculation in extreme conditions. on the list now.
crypto signals held better than expected. BTC dropped with equities monday, but the momentum signal disconnected from the equity panic faster — by tuesday afternoon, crypto was forming its own bid while SPX was still finding lows. the signal stayed data-driven and didn’t cross-contaminate. that felt like a win.
ES futures: flat exposure the whole week. the throttle was right to keep sizing minimal there. realized vol on NQ was 4x historical average for two days straight — no edge in that for my strategies.
execution quality during the spike #
this is where it gets interesting.
i ran the fill quality numbers for the week against Q1 baseline. here’s the comparison:
SPX options fills, normal market (Q1 baseline):
- theoretical mid: X
- average fill: mid + 0.12 (12 cents off theoretical mid)
- fill rate on limit orders: 94%
SPX options fills, monday and tuesday tariff spike:
- theoretical mid: X
- average fill: mid + 0.61 (61 cents off mid)
- fill rate on limit orders: 67%
that’s a 5x increase in effective slippage and a meaningful drop in fill rate. spreads that my backtest models assumed at $0.15 cost were actually running $0.78 effective cost per side. this is exactly the scenario that made my slippage model look naive when i audited it in Q1.
what the colo data showed: chicago round-trip latency during the spike averaged 1.4ms vs my normal 0.9ms. not a huge jump, but the entire SPX options market was having latency issues — CBOE quote updates were lagging, and my orders were hitting a book that was already moving before confirmation came back. network wasn’t the bottleneck; market structure was.
wednesday’s rally was the mirror image. once direction was clear, fills improved dramatically. limit orders filled quickly, spreads compressed, slippage dropped back toward normal within 45 minutes of the announcement.
week total: SPX options +$1,800, crypto +$4,900, ES futures -$500. net +$6,200. positive but nothing exciting — the throttle did its job of limiting damage during the bad days. wednesday was the save.
infrastructure under load #
a few things stood out in the infra data.
redis: cache hit rate dropped from a normal 94% to 71% during monday’s session. the cause was clear — market data update frequency increased significantly during the spike, and my cache TTL (time-to-live) settings assumed normal update rates. when quotes are refreshing 4x faster than usual, my cached values expired before they’d normally be used. effective result: way more direct database queries during the session that needed low latency most.
fix is straightforward — dynamic TTL based on realized quote update frequency. if market data is updating fast, cache life decreases. when it’s slow, cache life extends. writing this this week.
timescaledb: query times increased about 40% during the spike. acceptable — the increase was from higher write volume (market data ingestion) competing with analytical reads (my strategy calculations running continuously). nothing alarming, just something to monitor. considered read replicas but current query load doesn’t justify the overhead.
colo latency: as mentioned above — 1.4ms vs 0.9ms average, but max spikes were what surprised me. during the worst 90 minutes monday, i had 11 individual trades where round-trip confirmed in >8ms. those are outliers but they matter for limit order logic. the market moved before confirmation came back three times — filled at worse prices than the order specified. that’s a market structure problem, not my infrastructure, but i need to handle it in my execution layer.
the correlation is obvious and pretty much linear up to VIX ~28, then flattens. above 30, latency doesn’t seem to get much worse — but fill quality is already so degraded by that point that the latency number becomes less relevant. the slippage from market microstructure breakdown dwarfs any latency effect.
what i’m actually fixing this week #
three items, in priority order:
1. IV recalculation frequency scaling. when VIX is above a threshold (currently testing 22), switch the IV rank recalculation from 15-minute cadence to 3-minute cadence. costs more compute on the colo box, should be fine. the stale-signal problem during the spike was 100% a cadence issue.
2. redis dynamic TTL. formula i’m testing: ttl_seconds = max(5, 60 / quote_updates_per_minute). normal market: ~10 updates/min → 6 second TTL (close to current). vol spike: ~40 updates/min → 1.5 second TTL. keeps cache actually fresh under stress.
3. confirmation timeout handling in the execution layer. if a fill confirmation doesn’t arrive within 3ms (above my 99th percentile), treat it as uncertain and verify position state before placing additional orders. currently just waiting indefinitely for confirmation, which caused three bad sequences last week.
none of these are massive changes. all of them would’ve directly improved last week’s performance.
what actually went right #
i want to be honest about this: a lot went right.
the event risk throttle made it to production the week before it was needed. if I’d been running full size monday, the SPX book would’ve looked like early 2023. instead, positions were at 40% notional and the loss days were painful but survivable.
the roll engine (built two weeks prior) automatically defended existing iron condors as the underlying moved. i watched it fire four times monday — adjusting deltas, rolling strikes wider, taking small losses to avoid larger losses. i didn’t touch anything manually. the automation worked exactly as designed.
and the portfolio Greeks aggregation i finished tuesday of last week meant that when everything was moving simultaneously, i had a single real-time dashboard showing total portfolio delta, gamma, theta, vega. knew exactly where i stood at every moment. that’s new — two months ago i wouldn’t have had that visibility during a spike like this.
the NexusFi algo community was actively discussing the chaos all week. got some good perspective on how others were handling it — the thread Attack of the Robots had a bunch of people comparing notes on automated system behavior during the tariff moves. useful to see that a lot of systematic traders had similar experiences with execution quality degradation. not a bug in my system specifically — a feature of chaotic markets.
brief note on the week #
A. had her laptop out all week, deep in a client project. around 2 AM tuesday — worst of the stress, trying to figure out why my fill confirmation logic was producing inconsistent results — she just set a coffee on the corner of my desk without saying anything and went back to her desk. didn’t ask if i was okay, didn’t try to talk. just knew.
separately: my dad would’ve found all of this fascinating. the macro chaos, the algo behavior, the data. he was an engineer before anything else. moments like this week, i think about what it would’ve been like to talk through it with him. then i get back to the data.
back to work. redis TTL fix first, should be done by thursday.
-AK