Skip to content

Complex systems should make a business faster, not more fragile.

I design and lead the architecture behind high-load, real-money platforms, and help teams change them with confidence.

Abstract composition of interconnected nodes in dark graphite and orange, representing a distributed system

100K+

concurrent players per game, up from 20K, on platforms I architected

2 wks

time-to-market for new products, down from two months

+87%

delivery throughput with zero-downtime releases

20 yrs

in software, eleven of them in banking and payments

Correct under load. Clear under pressure. Safe to change.

Every ambitious product eventually meets the same wall: the system that got it here is now the thing slowing it down. I exist to move that wall.

Failure is a design input

Timeouts, retries, duplicate messages, disconnected clients. I make them explicit in the architecture instead of discovering them in production.

Evolve, don't rewrite

Adapters, explicit routing, tested boundaries. Modernization that keeps the business running while the platform changes underneath it.

Architecture is a team sport

Standards, mentoring and delivery practices that let forty engineers move like four. Good systems come from teams that understand them.

Work, in snapshots

Most of my recent work is under NDA. What I can share are the shapes of the problems and the outcomes.

Real-time gaming platform

From 20K to 100K+ concurrent players per game

Event-driven services, low-latency WebSocket flows and consistency rules that survived a fivefold load increase.

Payments and wallets

Wallet flows that stay correct under retries

Multi-wallet, demo balances, points and external providers with explicit idempotency and transaction safety.

Delivery transformation

Two months to two weeks

Platform standards and reusable capabilities that let a forty-person department ship 87% more, with zero downtime.

See the work

Thinking out loud

Practical writing on the failure cases behind simple APIs: timeouts, duplicates, concurrency and the cost of getting them wrong.

All articles
Portrait of Denis Pushkarev

Twenty years of systems that could not afford to be wrong

Eleven years building payment systems for a central bank. Then distributed platforms across Europe. Then four years scaling real-time gaming in Dubai, leading a forty-person engineering department. I still write code, and I still ask the same question: what happens when this fails?

Have a system that has to scale, stay correct, or both?

Thirty minutes. You describe the problem, I tell you honestly whether and how I can help.

Book a call