Petr Stankin

Technical

Go · gRPC · Protobuf · Node.js · TypeScript · NestJS · Kafka · RabbitMQ · MongoDB · PostgreSQL · ClickHouse · Redis · Docker · GitLab CI · Grafana · Kibana · Clean Architecture (Robert Martin) · DDD

Management

people management · hiring · one-on-ones · individual development plans · Scrum · quarterly planning · backlog management · event storming · on-call organization · adopting AI agents in development

Full version

Leading the courier domain team: courier hiring, the courier loyalty program and rating, regulatory reporting, breaking down the courier monolith. The team is one of the first in the company to move from Node.js to Go; all new services are written in Go following DDD and Clean Architecture. Launched 7 services from scratch.

Team team-lead, 3 Backend developers, 1 Frontend developer, 1 Android developer, 1 QA

Team management

• Rebuilt the backend team and moved it to Go. Hired a strong Go developer, retrained a backend developer from Node.js to Go, and grew a systems analyst into a Node.js backend developer, who then moved to Go with no trouble. The whole backend team now writes Go.
• Delegating technical decisions. Handed code review and architecture over to the developers; the team makes technical decisions on its own. I focus on people management and building processes.
• Processes. Moved the team from Kanban to two-week sprints with grooming and estimation before the sprint starts. Together with the product team we run capacity-based quarterly planning; large projects are tracked with Gantt charts by stage (design, development, testing, adoption). Rebuilt the on-call process for the new services.
• Working with requirements. Introduced a DDD approach to shaping work with the product team: event storming and domain modeling, scenarios in Given/When/Then format. Meetings are recorded and transcribed, and modeling artifacts are processed with AI. Time-to-market from idea to launch dropped from 120-150 to 60 days, and the team consistently meets it.
• Testing. Almost eliminated manual regression testing: Clean Architecture narrowed the regression scope, and checks moved to automated tests on the company's internal framework. Regression went from 2 days to a 15-20 minute pipeline run in the MR. QA validates scenarios during modeling and reviews the automated tests in MRs; the tests are written by QA or by developers with an AI agent.
• AI agents in development. Rolled out AI agents across the whole team. Following my brief, a senior developer built an internal framework: a repository with Docker Compose, access to corporate LLMs, the open source agent Letta, and MCP connections to the task tracker, Grafana, Kibana and GitLab. Onboarding a new hire takes 1 day: they spin up the environment, get access, and from there the agent finds what is needed in Confluence and across the infrastructure. Senior team members barely need to be pulled into onboarding. All code is written through the agent; the agent does the first review and a human does the final one.
• Contract first. Switched to an approach where contracts are described and agreed first (proto for gRPC, OpenAPI for REST), and only then does development start. With the contract in place, backend, frontend, Android and neighboring teams work in parallel without waiting on each other.
• Engineering practices. Among the first in the company to adopt feature flags, and proved them out on traffic switching during the monolith breakdown. Moved business logic from the Android app to the backend: the app renders what comes from the server, down to texts and element colors. These are the first steps toward backend-driven UI. Bugs are fixed on the backend without an app store release, and the load on our only Android developer goes down. Go services are built on the company's shared libraries, unit tests with coverage checks run in CI, Grafana dashboards live in the repository next to the code, and MRs require approvals and branch checks.
• Growing people. Introduced individual development plans in the team (the company has no such practice) and keep up regular one-on-ones. I maintain a team star map and assign work by level: the senior developer owns code architecture and the AI agent framework with memory, and I am growing a confident middle+ developer into a team lead; he is effectively my deputy now.

Delivered projects

• Courier loyalty program and rating (Go, gRPC). The largest service in the domain: 50,000 couriers in the program, with up to 100 events per courier per day. We moved the rating out of the courier monolith into a separate service and built the loyalty program on top of it. The program is rolled out to all couriers and has a positive effect on retention.
  • Loyalty: couriers get benefits (promo codes, certificates, partner discounts) based on rating level and city. Promo codes, certificates and courier lists are loaded via streaming CSV import; couriers get push notifications about new benefits.
  • Rating 2.0 (preparing for rollout): a new model built on DDD aggregates. It accounts for delivered orders, slot shifts and marketplace sessions, external incidents from Kafka, and violation-free shifts. The rating activates after the first delivery and an order threshold; a day can be recalculated retroactively.
  • Managed from the CRM: rating configurations, levels, onboarding and help content are set up in the admin panel; a new configuration is published automatically on schedule.
  • Rollout: the loyalty program was enabled step by step by delivery zone with A/B testing and dynamic feature flags via Kafka. Ratings from the monolith were moved with a dedicated migration tool.
  • Reliability: idempotent event processing, a worker pool for recalculation, service-to-service JWT authorization, support for all Russian time zones.
• Breaking down the courier monolith (Go). The monolith is many years old, and my team is doing the breakdown. 50% of the logic has already been moved out and runs in production in Go services on the new architecture; the hardest part of the work is done. New logic is built next to the working one, and traffic is switched to the new services with percentage-based feature flags that can be rolled back. Smooth switching has been verified in production with nothing breaking. The first context moved out was courier offer agreements: signing, offer availability rules by company, non-resident events. Data from MongoDB and files from object storage are migrated by separate migration commands with a dry-run mode and a runbook.
• BFFs for the courier mobile app and the admin panel (Go). Client traffic used to go through old proxy services; the domain had no dedicated BFFs. My team was the first to build both BFFs, and all teams in the delivery domain will use them going forward. Clients are isolated from internal gRPC contracts, with authorization in one place.
  • The courier app BFF validates the app token, identifies the courier and calls internal services over gRPC. It serves the rating, benefits and onboarding materials to the app with caching.
  • The admin panel BFF translates CRM requests into gRPC calls and checks user permissions for every method.
• Courier self-registration (Vue 3). Hiring was a new domain for the team. The web app is embedded into the mobile app via WebView. A candidate fills out a multi-step form (city, vacancy, personal data, passport, payouts and self-employment, document photos), signs in via SMS and sees the application status. There is a vacancy map with point clustering, rolled out after an A/B test. Candidates register without a recruiter.
• Integration with an external recruiting system (NestJS, inherited service). Refactored it, extended the contract with the external system, added retries, moved notifications to email and masked phone numbers in logs.
• Courier survey service (NestJS, new architecture). A survey builder: create, publish and close surveys on schedule, target couriers by an uploaded list, collect answers and export results to CSV. All use cases are covered by unit tests.
• Courier data service for regulatory reporting (NestJS). Collects order events and courier geolocation from Kafka, enriches them with data from courier services and sends them to a data mart for the regulator. Delivery state is tracked with a state machine; personal data is hashed.

Key achievement Moved the team to Go and cut time-to-market from 120-150 to 60 days.

Stack Go · gRPC · Protobuf (buf) · OpenAPI (ogen) · Node.js · TypeScript · NestJS · Kafka · MongoDB · Redis · MinIO · Vue 3 · Grafana · VictoriaMetrics · Kibana · Docker · GitLab CI · Letta · MCP

Full version

Led the team behind the third-party delivery integration service (3PL). The service hands orders to external partners when in-house couriers are not enough and processes more than 300,000 orders per day. A detailed description of the service is in the previous position (Backend Developer).

Player-coach team lead: combined managing the team with building key service features.

Team team-lead, 1 Backend developer, 1 QA, 1 Systems analyst, 1 Product manager

Team management

• Breaking down product tasks and assigning them to the team, code review, writing technical requirements, overseeing the service architecture.
• Quarterly project planning, backlog management, team vacation planning.
• Hiring. Filled a backend developer position, but the new hire could not handle the work, and I parted ways with him during the probation period. After that I hired a strong developer in his place.
• Introduced regular biweekly one-on-ones with everyone on the team. The team had no such practice before.
• Set up the on-call process for the service.
• Working with neighboring teams on delivered projects.
• Handing the service over to another team: prepared documentation and a knowledge base, ran the knowledge transfer.

Delivered projects

• Tracking of partner couriers' movement.
• Filtering out couriers based on an ML model forecast.
• Tech debt and reliability: refactoring the architecture into layers, introducing unit tests, a single alerting standard, optimizing MongoDB usage.

Key achievement Kept a 300,000+ orders/day service supported and evolving with an understaffed team, and handed it over to another team with documentation and a knowledge base.

Full version

Developed and maintained the third-party delivery integration service (3PL). When in-house couriers are not enough, the order goes to an external partner, and the service handles it end to end: receives the order from another service, picks a delivery provider, creates a request with it, tracks the status and handles cancellations.

More than 300,000 orders per day went through the service. It worked with five delivery providers, each with its own API and data exchange style. Some partners pushed request statuses via webhooks; the service polled the rest itself: a cron job pulled all active orders from the database (new, being assigned, en route), and RabbitMQ distributed the tasks across pods, so processing scaled horizontally. Events were exchanged with other company services via Kafka.

The main challenge was unstable external integrations. A partner could go down, time out or respond with errors, and then it was unclear what state the order was in: the partner had been assigned, and then nothing came back from it. These cases had to be handled correctly so orders did not get stuck and still reached the customer.

Team team-lead, 2 Backend developers, 1 QA, 1 Systems analyst, 1 Product manager

Tasks

• Service stabilization. When I joined, the service regularly went down in production. I refactored it and reworked the architecture, after which product development on it became possible. Requests to partners were moved to parallel processing, and batching and deduplication were added for request status updates. All external calls are covered by tracing; I added metrics for courier search time and paid cancellations, alerts on request creation errors, and global exception handling. Upgraded Node.js and the shared libraries for queues, metrics and Redis.
• Partner rating. Previously, the order in which delivery providers were called was hardcoded. Now the service collects request events (courier found, cancellation, delay) and recalculates each partner's rating per delivery zone on a cron schedule. Event weights and rating depth are configurable, with a blacklist and a management API. Before creating a request, the service asks partners for price and delivery time. Indexes were tuned and MongoDB queries optimized for the event stream. It turned out partners perform differently in different zones, so an order now goes to the one that performs best in that specific zone.
• Universal partner onboarding API. Previously, every delivery provider needed its own integration. Built a single contract through which a new partner connects, with support for rating and personal data masking. A new delivery provider is already connected through it.

Key achievement Stabilized a 300,000+ orders/day service that regularly went down in production, and launched partner rating on it.

Stack Node.js · TypeScript · NestJS · MongoDB · Kafka · RabbitMQ · Redis · APM · Grafana · Graphite · Kibana · Moira

Middle Backend Developer · Control Systems North-West JSC

March 2023 - April 2024

Development of a BI system core. Project teams use the core to build dashboards (tables, charts) for specific clients. Data is loaded into ClickHouse through an ETL process.

• Rewrote the data delivery logic: processing moved from the frontend to the backend, and large tables started rendering noticeably faster.
• SQL query generation from dashboard JSON configs, without an ORM.
• Reworked config typing and validation so dashboard developers immediately see where the error is.
• Logging service with storage in ClickHouse, new JWT authorization, unit tests, GitLab CI.

Stack NestJS · PostgreSQL · ClickHouse · Jest · Zod · Docker · GitLab

Backend Node.js Developer · Self-employed / Freelance

January 2021 - March 2023

Backend for commercial projects on a microservice architecture: an online store for imported goods, an NFT marketplace, a real estate search platform with Telegram bots. Database design, REST API, integrations with payment systems, CRM and external APIs, Docker packaging.

Stack NestJS · Express.js · TypeScript · MySQL · MongoDB · Docker · Nginx

CEO · PTK 47 LLC

November 2019 - January 2021

Ran the company: pricing policy, negotiations with key clients, training sales managers.

Sales Manager · OBI FC LLC

August 2016 - February 2019

• 2026Development Team Management, Yandex Practicum (March 2026 - September 2026)
• 2025HighLoad++ 2025, attendee
• 2025TeamLead Conf 2025, attendee
• 2022Backend Node.js Developer, Netology
• 2021Fullstack Python Developer, Netology