Skip to content
Engineering for the next change

Contents

Vladimir Sinyavsky / Engineering Lead / Software Architect

I take technical ownership where a system has many changes ahead

For 12 years, I have designed and modernized backend systems on .NET. My work spans payment flows, distributed integrations and legacy systems that must keep running while they change.

I combine architecture, hands-on engineering and technical leadership. I study the domain, draw system boundaries, make decisions explicit and carry them through to production.

Lead AI-native Engineer at Alfa-Leasing since October 2025

Contact CV PDF (Russian), opens in a new tab

12 years in backend engineering
More than 5 years of technical and team leadership

System

Domain, lifecycle, integrations, data and ownership boundaries.

Delivery

A reliable path to production, observability, quality gates and safe legacy evolution.

Team

Distributed technical decisions, growing leaders and shared engineering context.

01

Why I do this work

Early in my career, good engineering meant writing high-quality code quickly.

Then the products grew. New teams, integrations and requirements arrived, and every change touched more parts of the system.

Architecture became a daily practice. It lets me see how today's decisions affect the releases that follow.

I now focus on systems that must keep evolving years after their first release.

02

I start with the domain and constraints. Technology comes later

  1. 1 Understand the domain

    Where are the real domain boundaries, and why do the same words mean different things to different people?

  2. 2 Find the actual constraints

    I consider technical constraints together with product and organizational constraints.

  3. 3 Model the domain

    A model must support decisions. Describing the current code is not enough.

  4. 4 Design the boundaries

    Component and team responsibilities must remain clear as the system grows.

  5. 5 Choose the technology

    I understand the problem and its constraints first, then choose the technology.

  6. 6 Take it to production

    Production reveals how a decision behaves under load, across real integrations and with user feedback.

  7. 7 Observe and evolve

    New facts change the architecture. That is part of its lifecycle.

03

What I work on

New platform

Design a product system, establish its technical foundation and take the MVP to production.

Live legacy

Evolve a running system incrementally while preserving business processes and compatibility.

Team and ownership

Distribute technical decisions among engineers while keeping the system understandable to the team.

AI-native engineering

Test AI-assisted approaches in production work and keep the practices that create verifiable value for engineers.

04

Domains change. The same classes of engineering problems return

Dots from left to right: Payments, Travel, EdTech / Legacy, AI-native.

Selected problem

Complex domain

AI-native

This problem was secondary in this domain.

Selected problem

External integrations

Selected problem

Asynchrony and uncertainty

EdTech / Legacy

This problem was secondary in this domain.

Selected problem

Evolution without downtime

AI-native

This problem was secondary in this domain.

Selected problem

Reliability and observability

Selected problem

Engineering environment

21 of 24 intersections are backed by specific projects. In the remaining three, this problem was secondary to the domain.

Evolution without downtime appeared in legacy billing, running travel services and the incremental replacement of Rails with .NET.

05

Projects where I did this work

CASE-002

Travel & Business Travel

In travel systems, a simple search and booking flow becomes an aggregation of multiple GDS providers with separate booking, payment and settlement lifecycles.

Context. RuTrip handled about 300 RPS. The product had 40 filters, 4 booking scenarios, 3 payment methods and 2 settlement models with GDS providers.

What I did. I worked on aggregated search and booking, a Customer Journey Map and a shared domain language with product. We gradually moved the architecture toward vertical slices.

Outcome. Search latency fell from 20-30 to 6-8 seconds. Later, in business travel, I worked with external GDS providers and critical corporate systems used by more than 300 employees.

CASE-003

Evolutionary Legacy Modernization

A platform serving 20,000 active users depended on an unstable Rails API. The product had to keep running throughout the migration.

Context. The running product depended on an unstable Ruby on Rails API, and client applications needed a seamless path to the replacement.

What I did. I built a team of four backend engineers. We replaced routes incrementally with the Strangler Fig pattern while migrating data in parallel.

Outcome. Client applications moved to the new API without interruption. We released it in slices, met a tight deadline and kept the product available.

Recorded authorship. Rospatent registrations list me as a co-author of software created during my engineering work.

CASE-004

Engineering Organization

At FIN-RA, an investment EdTech product, the engineering organization grew from 5 to 15 people and split into two teams.

Context. The group grew from 5 to 15 people and split into two teams. The next constraint was the concentration of technical decisions in one lead.

What I did. I worked on hiring, one-to-ones, individual development plans and delegation. The teams adopted DDD, Event Storming, peer review, testing and DevOps practices.

Outcome. Three engineers grew into team leads. Each team gained its own area of technical ownership.

CASE-005

AI-native Engineering

I test AI agent instructions and AI-assisted delivery practices in real engineering work. The approach continues to evolve.

Context. The goal was to accelerate complex integration work and legacy modernization while keeping engineering decisions accountable and reviewable.

What I did. I created more than 20 versioned instructions for AI agents, established their delivery process, introduced them to backend teams and trained colleagues.

Outcome. I built an omnichannel call-center MVP in four months. In another project, I migrated a PHP legacy system to .NET / React in five weeks with AI-assisted engineering practices.

Active development

Open project

OSS-001

Travel Platform

An open project that shows domain modeling, architecture decisions and code organization. The Flights M1 backend is ready: a modular monolith with DDD, air-content provider integrations, resilience, observability and a separate AI service.

Next stages: Hotels, Rail, Trip Planning and the core AI service.

Open repository
06

Observations from practice

Good architecture matters more in a product's fifth year than in its first release.

The hardest problems often start with different understandings of the domain.

Teams and engineering processes also need to be designed.

AI changes how strong engineers work. Accountability for decisions stays with people.

07

Why this site exists

Early in my career, I looked for honest accounts of real projects: what people built, where they went wrong, why they chose a solution and what it cost them later.

Now I collect and publish those stories myself.

Architecture

Design that keeps working after the first release

Long-form analysis of decisions, constraints and the cost of change.

 Practice

Articles on Habr

DDD, distributed systems, legacy and engineering work with AI.

 Research

Interactive engineering case studies

How the order of decisions changes system structure and cost.

On Telegram: notes from engineering practice, article follow-ups and experiments with AI in senior and lead engineering work.

08

If you want to discuss a similar system or decision, get in touch

Email siniavsky.vladimir@gmail.com Telegram @vladimir_sva GitHub svasorcery Blog blog.vsinyavsky.ru Website vsinyavsky.ru Document CV PDF (Russian), opens in a new tab

I update this page as my projects and engineering experience evolve.