I’m doing software development since 2004. From that time, I’ve done several projects, participated in another number of teams and played with many different technologies, programming languages and frameworks.

Currently I work at Wildberries & Russ as Systems Architect in the platform employment domain. I oversee the financial perimeter: write-offs, penalties, disputes, and loss control.

In parallel, I develop practices for architectural oversight, system analysis, and business analysis. My focus is on automating these processes and integrating AI tools into team workflows.

Before that - IPONWEB (later acquired by Criteo), where I grew from Perl/Lua developer to Systems Architect of Commerce Grid.

Over these years I developed a simple algorithm - three questions before any task:

• Goal: what do I want to achieve?
• Reality: what do I know and don’t know?
• Action: what will I do right now?

Experience

WBJob - Architecture - Wildberries & Russ

Building system analysis, business analysis and architecture into the development process. Together with a fellow architect and a team of analysts, we establish standards and integrate into processes.

Main challenge: embed three stages (business analysis, system analysis, architectural oversight) into the development process without increasing time-to-market.

HRTech - digital transformation - Wildberries

Joined Wildberries as Systems Architect and built HR Tech as a manageable engineering system: system analysis practice, architecture as code, transparent integrations and delivery quality - instead of “we agreed verbally and shipped”.

What I built as organizational-architectural foundation:

• Built system analysis department from scratch: assembled the team, established the practice, and embedded system analysis into the development process (requirements elaboration, contracts, integration coordination, acceptance criteria).
• Implemented “Architecture as Code” approach: documented services and their responsibilities, captured key decisions through ADRs, built a service map and dependencies as a maintainable artifact, not “knowledge in heads”.
• Brought order to integrations: consolidated chaotic “verbal” integrations and manual token provisioning into a formalized approach - with a unified integration service, rules, automation and traceability.
• Introduced testing culture: launched testing practices where none existed, integrated checks into CI/CD pipeline, improved release predictability and change quality.
• Drove major initiatives to completion: took on large changes, drove them through teams and dependent stakeholders, closed “loose ends” rather than leaving them as eternal concepts.

Key product domains:

• HR Platform (HRPortal) - single source of truth for employees (warehouse + office/IT).
• ATS (Applicant Tracking System) - recruiting and onboarding, reducing dependency on external provider (HeadFlow).
• Team Management (WBTeam) - team management: vacancy requests, notifications, approvals.
• Compensation & Benefits (C&B) - calculation automation, tariffication and financial risk control.

Internal Control & Audit - SKU logistics - Wildberries & Russ

Accumulated SKU cost:

Architectural support for the system calculating accumulated service cost per item (SKU) across the entire Wildberries logistics chain: gate acceptance -> warehouse -> transport logistics -> pickup points. Each major stage consists of multiple processes, each adding operation cost. Understanding this picture provides a foundation for optimization - from individual operations to major processes (sorting, acceptance, last mile).

Warehouse operations tariffication:

Architectural support for the tariffication system. Specifics: all operations (warehouse + transport) are tariffed and paid - hourly, per operation, various output schemes. Enormous number of rules, nuances and legacy. Main constraint: warehouse must always operate, downtime is unacceptable.

Commerce Grid - platform architecture - Criteo

After IPONWEB was acquired by Criteo, I joined as Systems Architect to work on Commerce Grid - a retail media platform.

My key contributions:

• Created the initial C-Grid architecture model and established collaborative architecture practices
• Led Kubernetes migration for critical services with minimal downtime
• Built integration testing environment with Docker-based infrastructure for local development and CI
• Implemented service mesh, monitoring, and observability solutions
• Established architecture review processes and cross-team collaboration

The platform enables retailers to monetize their digital properties through advertising while maintaining user experience and data privacy.

DevOps & SRE - diving into operations - Criteo

Working as a developer, I often heard from devops: “this takes long”. Got curious - what takes so long? Dove into DevOps for a year and a half, fully focused on infrastructure tasks. Then heard the same from SRE - “complex, takes time”. Moved to SRE for another year.

Figured out how it all works from the inside: Google Cloud, AWS, Terraform, CI/CD pipelines. Now I understand both sides - development and operations.

BidCast - Load Balancer development - IPONWEB

One of the most complex projects. Two goals: decompose the BidSwitch monolith and test a hypothesis - can we build our own load balancer cheaper than Google/AWS.

First version proved: our load balancer is cheaper to maintain. Then we started moving logic from BidSwitch to BidCast - everything not tied to state and database, offloading heavy code.

Main achievement - AdTXT module: developed my own data storage format that allowed loading 5-6 GB into process memory in ~1 second and searching in 10 nanoseconds. This enabled extracting functionality from BidSwitch and saving tens of thousands of dollars per month. BidCast didn’t even notice the new module performance-wise.

BidSwitch - monolith decomposition to microservices - IPONWEB

Microservices were at peak popularity back then. Led the decomposition of BidSwitch monolith into microservices - created about 7 services behind an API Gateway.

How it ended: shut down the initiative. Microservices support turned out more expensive than monolith - need to grow teams, more people. With monolith one team ships features, maybe slower, but steadily.

What I gained: lots of practices, hard-learned lessons, deep understanding of tradeoffs. Main microservices benefit - ability to completely rewrite a service in 1-2 weeks. Can’t do that with a monolith.

uWorkflow - Django monolith - IPONWEB

Django monolith designed like a LEGO constructor - lots of small components. The system configured itself on the fly from a given schema. Configuration driven development: managing objects and relations through OpenAPI-compatible schemas. Schema was the heart of the system.

Result:

• Faster project delivery
• All code in one repository
• Small team supporting many projects

Became experts in Python, Django and DRF.

YouZoo - social network for pets - 2 years in SEA

Spent two years traveling across Myanmar, Thailand, Laos, Vietnam, Cambodia, Malaysia, Indonesia, the Philippines, Nepal, India, and Sri Lanka.

During this time, I focused on deep self-learning and skill-building:

• Learned Python and built a small social network for pet owners
• Studied PostgreSQL and understood how to model and query structured data
• Switched fully to Emacs, building my own productive workflows
• Taught myself blind typing in English - to code and write faster
• Developed clarity, focus, and the ability to learn independently - skills I rely on every day in architecture and engineering

This journey shaped not only how I live, but how I think.

Рассылки - email marketing - Mail.Ru

30-40 million personalized emails per day. Two main challenges: Mail sender and Targeting machine.

Mail sender in Perl with event loop. Hardcore times: daemons, interprocess communication, sockets, synchronization.

Targeting machine - first AdTech experience. Personalized targeting for each email. Developed a data structure with custom hash function: checking all variants in O(1). AdCache was huge but worked super fast.

Learned TDD on this project - been writing tests for all my code ever since.

Mission

Helping companies transform complex systems into manageable architecture with clear boundaries, reliable integrations, and predictable evolution.

This isn’t about beautiful diagrams or trendy frameworks. It’s about:

• Developers understanding where their responsibility ends
• Changes in one service not breaking ten others
• New team members being able to understand the system in days, not months
• Business being able to plan development knowing the real cost of changes

Complexity is inevitable. Chaos is not.

Values

Clear boundaries of responsibility

Each component knows its zone and doesn’t intrude on others. When boundaries are blurred, any change becomes an archaeological dig - who uses this? who will this break?

Contracts over verbal agreements

If an integration isn’t formally described, it doesn’t exist. API contracts, data schemas, SLAs - everything must be documented. “We agreed on this during a call” is not a contract.

Measurable outcomes

If you can’t measure it, you can’t improve it. Architecture metrics, test coverage, response time, coupling between modules - everything should be a number, not a feeling.

Reliability by default

The system should work predictably, not “usually works”. Graceful degradation, retry policies, circuit breakers - not options, but baseline requirements.

Simplicity and evolvability

Complexity grows only when truly necessary. Every abstraction must justify its existence. Three similar lines of code are better than a premature abstraction.

Philosophy

70/30 approach

Conservative-risk-oriented balance. 70% of decisions use proven, reliable approaches. 30% are controlled experiments with new technologies and methods.

I work only with manageable risks. This means:

• Clear criteria for success and failure
• Rollback plan before starting changes
• Isolation of experiments from critical paths

Context over templates

Good architecture starts with understanding context, not applying ready-made solutions. Each system is unique and requires its own approach.

“Best practices” are someone else’s experience in someone else’s context. Useful to know, dangerous to copy blindly.

Explicit boundaries of responsibility

Not just in code, but in processes. Who makes the decision? Who bears responsibility for consequences? Who has veto power?

Blurred boundaries are a source of conflicts and decision paralysis.

Places I’ve been

Actually to remember all the places I’ve been is very difficult task and only my wife is able to help me with it. Thank you dear, I love you!