Roman Sapezhko/Performance Engineer · 10+ years · high-load & reliability
I dig into Python backends and distributed production systems — CPU, memory, RPS ceilings, queues, and failure modes — so critical paths stay fast and stay up.
I don’t stop at recommendations. I profile hot paths, memory pressure, queue lag, and retry storms — then harden the distributed path so load and failures don’t take you down.
No pitch deck. We map RPS ceilings, CPU/RAM pressure, and failure modes — and what to fix first.
Try it — watch the numbers move
Production signals
beforeCPU (process)
87 %
RSS memory
1.8 GB
CPU over time
500+
API RPS
sustained load
99.9%
API uptime
under load
+35%
Throughput
B2B platform
2500+
msgs / min
IoT delivery
Fit
Self-qualify in thirty seconds — or take the quick check. The diagnostic is free; time is reserved for teams who feel the pain in production.
How I work
Same loop whether the bottleneck is a CPU-hot Python path, a memory leak, an RPS ceiling, a queue without backpressure, or a retry storm across services.
01
Profiles, traces, and production signals — CPU, RAM, RPS ceilings, queues, retries — not guesswork or generic audit checklists.
02
Rank fixes by conversion, reliability, and cost — so the first wins matter under real traffic.
03
Change the code and runtime, then add fault-tolerance and monitoring so load and failures don’t take the system down again.
Selected work
Some employers stay confidential — the numbers don’t.
01·GDS Group
Analytics took hours, throughput was capped, and deploys were slow — while holding a 99.9% API uptime bar. Raised sustained RPS and cut backend load without trading away reliability.
02·Trust Box
Stabilized an always-on distributed booking system after a contractor left: queues, payments, QR access, delivery guarantees, and observability under continuous message load.
03·E-commerce (confidential)
Slow production storefront: weak caching, heavy origin work, manual deploys, no performance gate. Cut origin wait and hardened delivery so releases stay fast under traffic.
What teams say
“Roman took our Django monolith from “works in staging” to predictable releases. API latency dropped, on-call got quieter, and we finally trust the deploy pipeline.”
“We needed real-time device telemetry without losing messages at peak load. Queues, monitoring, and clear runbooks — production stopped being a black box.”
“Clear scope, no architecture theatre. Weekly updates, tests in CI, and backend decisions explained in business terms — not slide-deck jargon.”
Sample deliverable
Example output shape — not a free full audit. Numbers illustrative of a typical SaaS API under rising RPS.
Diagnostic summary
Acme SaaS · checkout + billing API
P0
Pricing dependency p95 ~1.8s; no circuit breaker; retries amplify load across services and saturate CPU.
Impact: Cascading timeouts at peak RPS — abandonment and error budget burn
P1
Worker RSS climbs across the shift; large ORM graphs retained; GC pauses spike latency and drop effective RPS.
Impact: OOM kills and backlog during month-end
P2
Downstream API slows; consumer keeps pulling; lag grows without load-shedding or DLQ policy.
Impact: Silent data delay and uneven node load in a distributed path
Suggested next steps
Before the call, note: (1) product URL if shareable, (2) what’s slow/fragile — CPU, RAM, RPS, queues, timeouts, (3) what “fixed” looks like — p95, uptime, RPS target, or quieter on-call.
The offer
You’ll leave with a priority list for RPS ceilings, CPU/RAM pressure, or fragile failure modes — even if we don’t work together. Not a full audit. Not free implementation.
Before the call, note: (1) product URL if shareable, (2) what’s slow/fragile — CPU, RAM, RPS, queues, timeouts, (3) what “fixed” looks like — p95, uptime, RPS target, or quieter on-call.
After the call
The diagnostic is free. Paid work is scoped only if there’s a fit and a measurable outcome. Ranges below are starting points — final scope after the call.
Free · 30 min
No obligation
Symptoms → RPS / CPU / failure-mode map → priority order. Leave with a next-step list even if we don’t continue.
From €1,500
Scoped after call · typically 1–2 weeks
Deep dive on one hot path or failure mode (API RPS ceiling, worker, queue, memory) with profiles, root-cause notes, and a ranked fix plan.
From €4,000 / mo
Scoped after call · weekly delivery
Raise throughput and harden failure modes in code and runtime — circuit breakers, queues, budgets — so RPS and uptime hold on the next release.
About
Performance Engineer · high-load & reliability · Cheyenne, Wyoming, United States · Remote · 10+ years in production
I step into stressed engineering teams and earn trust fast — speaking the same language as backend, DevOps, and product within days, not weeks. Then I stay hands-on: I write the fix, harden the pipeline, and leave guardrails so the team can keep shipping.
I work with teams dealing with high CPU, memory leaks, RPS ceilings, cascading timeouts, or distributed systems that got harder to scale after rapid growth, legacy complexity, or AI-assisted development. Deepest focus: Python backends (Django / FastAPI) under real traffic — profiling code and runtime, queues, and fault tolerance — including OTUS Highload Architect training.
What happens next
FAQ
No. It’s a diagnostic. You’ll leave with a priority list even if we don’t work together. No pitch deck.
Not for the 30-minute diagnostic. A URL, stack notes, and what’s broken are enough. Deeper access comes later if we engage.
Python is home base — Django, FastAPI, Postgres, Redis, Celery — plus nginx, Docker, CI/CD, and production observability. I go deep on CPU, memory, RPS ceilings, query plans, queues, and failure modes in distributed paths (retries, backpressure, delivery guarantees). The method transfers across stacks.
I don’t stop at recommendations. I identify real bottlenecks and fragile failure modes in code and runtime, prioritize by business impact, and can support implementation.
A full audit, code fixes, load-test suite, or a guaranteed uptime number. Those are scoped engagements after we know the problem.
No. Many pains show up at the seams — queues, caches, downstream APIs, retry storms. I look at the path under load, not only one process in isolation.
If there’s a fit, we scope a focused audit sprint or a fix-and-harden engagement. If not, you still keep the priority list — no retainer pressure.
Quick check
Three questions. No email gate. You’ll get a read — then book if it still makes sense.
No pitch deck. We map RPS ceilings, CPU/RAM pressure, and failure modes — and what to fix first.