VladimirIvanov

The task was to distribute market data to multiple recipients with low latency. I split the work into several stages.

• Designed orchestration for a repeatable AWS EC2 test environment using Terraform and SSM, with ENA PHC/chrony clock synchronization, to give the AI agent a reliable feedback loop for optimization iterations.
• Configured the system to reduce jitter: CPU pinning and isolation, IRQ affinity, tickless cores, RCU callback offloading and hugepages.
• Optimized a lock-free SPSC ring buffer in shared memory. Cache-line isolation and zero-copy handoff cut transfer latency by hundreds of nanoseconds.
• Built the main transfer pipeline in C++23 with UDP unicast and DPDK kernel bypass. Designed a compact, self-contained, lossless wire format tailored to ENA LLQ/Wide LLQ. Added adaptive event batching within the MTU to balance latency and throughput, and applied further techniques to shave off fractions of a microsecond.
• Ran controlled A/B comparisons of the final version and prepared a detailed report with latency distributions, saturation points and other performance graphs.

Separate city datasets were a limitation built into 2GIS from its beginnings. Users could only work within one city, even when two cities were close together, like Samara and Tolyatti. They could not plan a route from one to the other, search across the boundary or see the results on a shared map. Solving this required rethinking the architecture of the entire application and the data flows feeding it. Almost every core module needed changes, from the update system to the map, directory and beyond.

I was responsible for delivering this project across the whole department, not just my team. I broke down the work, identified cross-team dependencies, created and maintained the roadmap, ran regular coordination meetings with adjacent teams, designed the architecture and personally implemented several complex components.

The second legacy of 2GIS’s origins as a PC product distributed on CDs was its offline-first model. In the 2020s, asking someone to download hundreds of megabytes after installation before they could start using the app was too high a barrier. Users left at the database-download screen, which also made a major advertising investment wasteful: much of the acquisition budget would be lost before people even tried the product.

Online mode had to be ready for an advertising campaign scheduled exactly a year ahead. This meant a major transformation of a live application: the map, directory, search and data-loading model had to support several modes at once, while regular releases and parallel feature development continued. I led the entire feature, working through difficult trade-offs between architectural constraints, product requirements, performance and deadlines.

Midway through development, I realized that the chosen approach to backend interaction was falling short of expectations. I designed a new one that combined fast responses with data consistency, which was critical to both the product and the core architecture.

A few months before the deadline, it became clear that we could not finish with the engineers we had. I escalated the need for additional engineers from adjacent teams and, once again, worked with the product manager to revise the scope of must-have features for the first release. Replanning, daily coordination, clear checkpoints and systematic stabilization helped us deliver the project.

We launched online mode on time, reducing the churn rate immediately after installation from 22.3% to 7.3%.

The new Zenith 3D engine had been in development for about seven years and was designed to bring fundamental changes to the product: a seamless map, online mode and flexible styling. It also introduced a completely new data storage format, incompatible with its predecessor, and a different API. These differences made integration exceptionally difficult, with no way to sidestep the underlying incompatibilities. I took on the task and worked through it step by step.

I started by building a prototype to explore the entire path: from calls to the engine API, through new core interfaces, to rendering frames in a Qt/QML application.

I then designed runtime and compile-time flags to isolate the new integration. This let us carry out a long development effort on the main branch without affecting production code before release.

Next, each component that used the engine needed either a parallel implementation against the new API, making full use of its capabilities, or a temporary adapter to speed up integration.

Migration was a separate challenge. We could not let users with old-format data suddenly lose the ability to use the app. I proposed selecting the engine at runtime based on the available data format and recreating the entire core session when switching between incompatible datasets. This let users move smoothly to the new version without disruption.

The existing delivery mechanism had a long list of problems: memory spikes when loading and updating data, a large idle memory footprint, slow queries, and unreliable data storage. Fixing each problem separately would add up to a major effort, with no guarantee of success.

I proposed an alternative: redesign the entire system for a comparable amount of work. At its core, I put our compact proprietary read-only key-value database, which offered high compression and fast queries. To support an EAV data model with complex filtering, I added hash indexes — one for each distinct filter used in the product.

To support frequent updates without downloading the entire database, I designed a system of patch databases. The difference between two data snapshots becomes a small, separate database in the same format. For a given base database, only the patch needs to be downloaded again. The client merges query results on the fly to produce the target data view.

Before committing to a refactor of this scale, I used inexpensive prototypes to prove that the design met the performance and data-size targets. That resolved the core uncertainty before we invested in implementation.

CI in the 2GIS core team started as a minimal set of Jenkins jobs configured by developers to check the master branch after merges. Under my leadership, it became a dedicated area of work with its own goals, priorities and roadmap, and the infrastructure developed into a mature solution.

• Dramatically reduced build times by introducing compiler caches and optimizing Git operations.
• Tracked down and fixed sporadic MSBuild failures that no one had managed to resolve.
• Built the tooling and organized the move to mandatory PR checks with automated merging of coordinated changes across multiple repositories.
• Set up test coverage reports.
• Championed Infrastructure as Code within the team. Migrated Jenkins from a Hyper-V VM to OpenStack, defined its configuration in Heat Templates and Ansible, and set up daily backups with burp from LVM snapshots.
• Hired an engineer to help and gradually handed over ownership of CI.

Our TypeScript library was the main way users interacted with the cluster, so we decided to move the CLI from Go onto that library too. This would eliminate the need to maintain two implementations that occasionally behaved differently.

Go had set a high bar for the CLI executable’s portability, so we wanted the new version to ship as a single statically linked binary too.

That turned out to be difficult. Our build system used Nix, which could theoretically build packages from its catalog statically. In practice, it was far from straightforward. I worked through numerous build failures, adding patches and configuration flags along the way. Some problems were specific to macOS, including codesign inside Nix’s hermetic build environment.

The next hurdles appeared when packaging our oclif-based CLI as a SEA (Single Executable Application — Node.js’s experimental support for single-file distribution). I effectively had to implement a small virtual filesystem by patching require.

The statically built Node.js runtime could not load libraries dynamically, so I also had to replace some native dependencies with WASM implementations.

I also worked on startup performance to make the switch to the new version smooth for users.

Built a vision-board service from an idea into a working product with real users and payments.

Owned the project end to end: made product decisions, designed the architecture, developed, tested and operated the service on Google Cloud.

• Organized development with AI agents using SDD: task definition, thorough plan review, implementation, code review and refinement based on test results. Around 95% of the code was AI-generated. TDD and E2E tests with Playwright/pytest provided fast feedback.
• Built a self-contained development and testing environment with local storage implementations and an emulator for successful and failed payments. The app and E2E tests work offline, including the complete purchase flow.