Selected Work - Dmitrii Lutskov

High-load e-commerce, owned end to end since 2009

One of its market's longest-running online electronics retailers: a Rails core, a C# ERP integration, automated pricing across a dozen-plus supplier feeds, and the analytics on top.

I have run the technical side of a consumer-electronics store since 2009 and kept it reliable across years of continuous change. It works as an integration hub. A 1C ERP sits on one side, a dozen-plus distributor APIs feed catalog and pricing on the other, and an automated pricing engine with dozens of factors decides the offer. The Rails core serves both B2C and B2B. A C# service I took over and largely rewrote keeps catalog and stock in sync with the ERP. Search runs on Manticore, while MySQL, Redis, and background workers carry the load. It has moved from bare metal to the cloud over the years, with some components in plain Docker, and it stays up: about 60,000 SKU at 99.8% uptime. A performance-marketing analytics layer sits on top, so engineering is tied to revenue rather than running beside it.

Built to last

In continuous development since 2009 and still shipping, at roughly 60,000 SKU and 99.8% uptime. No rewrite: the system is the business, and the work is keeping it reliable while it evolves.

Integration hub

A 1C ERP on one side, a dozen-plus distributor APIs on the other, and an automated pricing engine with dozens of factors setting the offer across B2C and B2B.

Owned end to end

Architecture, the Rails core, the C# ERP sync, search, data, bare-server infrastructure, and the marketing analytics, all run by one engineer.

Ruby on RailsMySQLRedisSidekiqManticoreC# (1C ERP sync)NginxPassenger / Puma

GPS-watch tracking platform

A device-to-app tracking platform built end to end, from a hand-written C socket listener that speaks the device protocol up to the Flutter apps and a live map.

I designed and built the server side and backend of a platform that tracks GPS wearables and shows their location in real time, and I was the only engineer on that part. Consumer trackers are not friendly clients. They hold a long-lived TCP connection over a mobile network and speak a compact binary protocol packed with location, motion, battery, cell, and WiFi data and alarm flags. A dedicated listener written in C handles the connections, forks a process per device so one bad connection cannot block the rest, and parses each frame by hand before anything is written. Telemetry goes into PostgreSQL with PostGIS, where database triggers keep "where is it now" cheap and reject physically impossible jumps. The Rails backend carries the rest: a versioned API, the alarm and response workflow, geofences, roles, real-time delivery over WebSockets, and mobile push for alarms. Commands flow back down the same connection, sent to the device in its own format. I built the Flutter apps on top, and a web map renders tracks and live positions. It shipped to production, with real devices in the field.

Low-level, by hand

A C listener on Linux holds many long-lived device connections, a process per connection, and parses a compact binary protocol field by field, with validity checks before any write.

Spatial data that stays cheap

PostGIS for the spatial model, with database triggers that keep the current position a fast lookup and reject impossible location jumps at the data layer.

Real time, end to end

Storage is split from delivery: the listener stores, the backend broadcasts over WebSockets and pushes alarms, and a command channel sends instructions back to the device.

C (POSIX sockets, libpq)Ruby on RailsPostgreSQL + PostGISRedisWebSocketsFlutterOpenLayers

Protected DNS and traffic-filtering platform

A layered defense that sits in front of customer sites: authoritative DNS, an external scrubbing layer, and an internal nginx protector doing the L7 work.

I architected and currently lead engineering for a service that shields customer sites from bots, abuse, and volumetric attacks. It pairs authoritative DNS with two lines of defense. In front, an external load-balancing layer absorbs L4 and volumetric attacks: botnets and DDoS. Behind it, an internal protector built on senginx (a security-focused nginx fork) does the L7 work: robot mitigation, bot filtering by pattern and user-agent, whitelists, port forwarding, and certificate handling. Request, attack, and bot statistics sit on top. When something fails, the platform pinpoints exactly where it broke: at the external balancer, the nginx protector, or the customer origin. It then shows the visitor a clear, service-branded page instead of a raw error. Built for multi-tenant scale on Kubernetes.

Two lines of defense

External load balancing absorbs L4 and volumetric attacks (botnets, DDoS) in front. An internal senginx protector behind it handles L7: robot mitigation, bot filtering by pattern and user-agent, whitelists, and port forwarding.

DNS at the core

Authoritative DNS as the entry point, with record protection routed through host load balancers.

Threats made visible

Request, attack and bot statistics in real time, so decisions rest on what traffic is actually doing rather than on guesses.

PowerDNSsenginx (nginx fork)RubyGoKubernetesL4/L7 protectionrobot mitigation

E-commerce platform, scaled under load

A platform inherited from a previous team and reworked, over three years, to go from falling over near a thousand users to holding tens of thousands, on Kubernetes.

I took over a commercial e-commerce platform for a publisher of print and digital editions after the original team left, and became the sole engineer on the web and the backend. The product worked but was raw, and it fell over near a thousand concurrent users. Over three years I reworked the architecture while still shipping features. A service and interactor layer kept request handling thin and testable. Shared eager-loading removed N+1 queries. Redis caching isolated slow and failure-prone third-party calls. Slow work moved off the request path into a message queue and background workers, the database was tuned and indexed, and a versioned API kept the client apps working as the system changed. While the Kubernetes cluster was initially run by a separate ops team, when the platform buckled under its first real traffic, the fix was mine: I went into pod resourcing and limits, load-tested the system, and reworked the code to hold up. It went from failing near a thousand users to tens of thousands of concurrent live users, and load-tested to roughly 150,000 requests per minute on 64 pods.

From raw to resilient

Took over a fast-built codebase after the original team left and reworked it, over three years, to serve tens of thousands of concurrent users while still shipping features.

Engineering for load

A service layer for thin, testable request handling, eager-loading to remove N+1 queries, Redis caching to isolate slow third parties, async offload to a queue, and targeted indexing.

Infrastructure ownership

The cluster was managed by an ops team, but when it buckled under real traffic, the scaling work was mine: pod resourcing and limits, load testing, and code that holds up under pressure.

Ruby on RailsPostgreSQLRedisSidekiqRabbitMQKubernetesversioned API

Systems built to hold up