Engineering
The part of the system where mistakes cost the most: load, money and servers. This is where 18 years of experience pays directly.
Engineering
Backends rarely fall over from request volume alone. They fall over because the data model wasn’t built for growth, a payment was captured twice, a background job hung — and there’s no monitoring, so you hear about it from users rather than from the system.
My background here is fairly specific: the backend of the Block.io crypto wallet at roughly 300,000 users, a payment service turning over about a million dollars a day, and a distributed network of ~1500 devices under production load. Plus antifraud and DDoS protection.
Hence the habit of designing for growth, for a third-party outage, and for the payment gateway that delivers the same webhook twice.
Designed for the growth you expect, not today’s volume. Indexes, denormalisation where it earns its keep, and clear boundaries between services.
REST or whatever fits: versioning, rate limiting, idempotency, meaningful errors, and documentation you can integrate against without a call.
Payment capture, subscriptions, credit models, in-app purchases. Correct handling of repeated webhooks, refunds and partial captures — so the money reconciles.
Profiling, caching, queues, background jobs. Finding the actual bottleneck instead of scaling the server on a guess.
Servers, reverse proxy, TLS, atomic releases with a rollback path, backups. Predictable deploys instead of copying files by hand.
Metrics, alerts, logs you can run an incident review against. Rate limiting, antifraud logic, brute-force and DDoS protection.
If the system already runs, I find where the bottleneck actually is and what actually breaks. It’s often not where people were looking.
A solution outline and an order of work. Changes are split into steps that can each be shipped and rolled back on their own.
Changes go in without stopping the running system: backward-compatible migrations, staged rollout, a way back to the previous version.
After rollout: metrics and alerts, so a deviation is visible before a user writes in about it.
It depends on scope: an API for a mobile app and a payment system with antifraud are different orders of magnitude. Billing is hourly. Describe the job and I’ll give an orientation.
Yes — that’s a job of its own. Measurement and locating the real bottleneck first, then an estimate for the fix. The first improvements often cost noticeably less than people expect.
Russian and international gateways, subscription models, App Store and Google Play purchases, crypto payments. Poor gateway documentation is a normal working condition, not a reason to decline.
Yes. I can take a defined area — the payment layer or the infrastructure, say — and hand it over to your team with documentation.
Rate limiting, brute-force protection, server-side receipt and webhook validation, secrets kept out of the repository, TLS. The engineering background includes antifraud and DDoS protection.
Whichever we agree. I can hand it to your administrators with documentation, or keep running it myself — also hourly.
This site uses cookies and Yandex Metrica to understand traffic. By continuing to use the site you agree to this. Learn more