Micheal Vance

Tech Lead

[Micheal Vance @michealspread]

Alright, time to get to work.

[Micheal Vance @michealspread]

Had one of those rare afternoons where I could actually put Slack on mute and code for a few uninterrupted hours.

No meetings. No “quick question.” Just headphones, coffee and one problem I've wanted to clean up for weeks.

Forgot how satisfying that is 😂 By the end I had fewer lines of code than when I started, which usually means it was a good session.

[Micheal Vance @michealspread]

Spent part of today reviewing what happens when one of our services starts responding slowly instead of actually failing. Hard failures are easy — you detect them and react. A service that's technically alive but taking 8x longer than normal is way more annoying.

We adjusted some timeout logic, changed how downstream requests degrade under load and ran the ugly scenarios again. Much cleaner now.

Reliable systems aren't just about surviving things going offline. They're about behaving predictably when everything is technically online but nothing is behaving normally.

[Micheal Vance @michealspread]

Finally had time today to clean up my desk after pretending the growing collection of coffee cups was part of the setup 😂 Found notes from an architecture discussion we had months ago and realized half the problems written there simply don't exist anymore.

It's easy to spend every day looking at what's still broken or what needs to be built next.

Sometimes it's nice to accidentally find a little reminder of how much the team has already shipped.

[Micheal Vance @michealspread]

Spent a good part of today stress-testing one of the execution paths after a few changes we pushed recently. Normal traffic looked perfect. Then we started throwing ugly scenarios at it — bursts, delayed responses, duplicated events, random service failures.

That's where things actually get interesting.

Found two edge cases that probably would've stayed invisible for months under normal conditions. Nothing dramatic, but exactly the kind of stuff I'd rather discover at 2pm during testing than at 2am in production.

[Micheal Vance @michealspread]

Had coffee with one of our engineers this morning and somehow a casual conversation about weekend plans turned into a 40-minute discussion about simplifying part of our liquidity infrastructure.

No meeting invite, no architecture doc, no whiteboard. Just two people drinking coffee and going “wait… why are we even doing it this way?”

Came back to the office, tested the idea and it actually works. Sometimes the best technical meetings aren't meetings at all.

[Micheal Vance @michealspread]

Spent almost three hours today debugging something that ended up being a one-line fix. Peak software engineering 😂

The funny part is we had logs everywhere, monitoring looked normal and every individual service was behaving exactly as expected. The issue only appeared when two events arrived within the same tiny execution window.

Fixed it, added a test specifically for that edge case and moved on. Three hours finding it, thirty seconds fixing it. Pretty normal Tuesday.

[Micheal Vance @michealspread]

Finally got rid of a piece of legacy logic that's been annoying me for months 😂 Around 600 lines disappeared and somehow the service now does more than it did before.

That's probably one of my favorite feelings in engineering. Adding functionality while reducing the amount of code responsible for it.

Less state, fewer branches, fewer weird edge cases and one less thing we're going to have to explain to ourselves six months from now. Good day.

[Micheal Vance @michealspread]

Spent most of today looking at something nobody notices until it stops working: reconciliation between internal states after partial execution.

The annoying part is that every service can technically be correct while the global state is temporarily wrong. Request A completes, request B times out after execution but before confirmation, request C reads the intermediate state... and suddenly you've got three different versions of "truth" floating around.

We ended up moving more of the recovery logic toward deterministic reconciliation instead of trying to prevent every possible failure. You can't design distributed systems where nothing ever fails. You design them so failure is boring.

[Micheal Vance @michealspread]

Been reviewing how we handle failure states across some of our liquidity infrastructure. Happy-path performance gets all the attention, but I'm much more interested in what happens when three things fail at exactly the wrong time.

Retries, idempotency, stale state, partial execution, reconciliation — that's where architecture gets interesting. A system that processes 10k requests/sec in perfect conditions is cool. A system that knows exactly what to do when conditions aren't perfect is much cooler.

[Micheal Vance @michealspread]

Spent way too much time today chasing a bug that looked like a routing issue but had basically nothing to do with routing.

We were getting inconsistent execution states under bursts of concurrent requests. Logs looked fine, individual services looked fine, tests looked fine. Turns out the problem was timing between two perfectly healthy services making perfectly reasonable assumptions about each other 😂

Changed the synchronization logic, ran the load tests again and everything flattened out. Distributed systems in a nutshell: nothing is broken individually, everything is broken together.

[Micheal Vance @michealspread]

Wrapped up another architecture review with the team today. I always tell new engineers that the first implementation is almost never the final one, and that's perfectly fine. Good systems evolve because people aren't afraid to challenge their own assumptions.

One thing I appreciate about our engineering culture is that nobody is trying to prove they're the smartest person in the room. We question ideas, not people. That's how reliable software gets built.

[Micheal Vance @michealspread]

Spent most of today profiling one of our core backend services and found something interesting. Everyone was focused on optimizing compute time, but the real bottleneck turned out to be synchronization between services. Once we reduced unnecessary state propagation, response times became much more consistent without touching the infrastructure. Sometimes the fastest optimization isn't writing better code—it's removing work that never needed to happen in the first place.

Days like this remind me why I enjoy distributed systems. Performance is rarely about one brilliant solution. It's usually dozens of small decisions that compound over time.

[Micheal Vance @michealspread]

Last sunday

[Micheal Vance @michealspread]

I've been looking into liquidity state convergence under asynchronous settlement conditions.
Current simulations approximate the system using:
Λ(t)=Σ(qᵢ·ωᵢ·e^(−λΔt))
subject to
∂R/∂t→0 as t→∞.
The objective isn't maximizing throughput but minimizing state divergence during concurrent execution while preserving deterministic reconciliation across settlement windows.
What's interesting is that execution consistency begins to outperform nominal throughput once contention exceeds a certain threshold.
Engineering is full of problems where the obvious metric turns out to be the wrong one.

[Micheal Vance @michealspread]

Spent the sunday hiking instead of sitting behind a monitor.
no GitHub.
no dashboards.
no logs.
Just mountains, fresh air and way too many photos of the sunset.

[Micheal Vance @michealspread]

Huge respect to our engineering team this week.
We managed to finish an optimization milestone right on schedule despite having production fixes, infrastructure maintenance and a pile of feature requests landing at the same time.
Nobody complained / nobody panicked.
Days like these remind me why great teams outperform great individuals every single time.

[Micheal Vance @michealspread]

Some people think engineering is writing code.
Honestly?
Most of my week is reading code someone else wrote six months ago and wondering what past-us was thinking 😂

[Micheal Vance @michealspread]

Been experimenting with adaptive liquidity routing models recently.
Instead of minimizing only latency, we're evaluating execution quality using a weighted objective function:
argmin J = α·L + β·σ + γ·ΔS
where L is routing latency, σ represents short-term execution variance, and ΔS is observed spread deviation.
Interesting thing is that reducing latency beyond a certain threshold barely improves execution quality. Distribution consistency matters much more than raw speed once you're already operating in the low-millisecond range.

[Micheal Vance @michealspread]

Finally got outside for a few hours today. Grabbed coffee, walked through the park with my wife and completely ignored Slack. Didn't realize how much I needed that until my phone stopped buzzing every two minutes. Tomorrow it's back to code reviews, deployments and way too many tabs open in brws.