Skip to content
serdjukow.eu

Sergej Serdjukow, Software Engineer, Berlin, Germany

Software that keeps working when things fail.

Scalable web applications and event-driven systems on AWS — built for retries, duplicates and traffic spikes.

  • Next.js
  • TypeScript
  • AWS
  • Serverless
  • AI

Decorative animation: a simulated event-driven pipeline. Events flow from producers through an API and a queue to a pool of six workers and into a store; failed events are retried with backoff and moved to a dead-letter queue after three attempts.

Focus

Selected engineering

  • Async processing

    Queues, schedulers and webhooks that keep long-running jobs moving, with retries, dead-letter queues and reconcilers.

  • AWS Serverless

    Amplify Gen 2, AppSync, Lambda, DynamoDB, SQS and EventBridge Scheduler in production.

  • AI in products

    LLM features inside real workflows: AI-scored websites, generated emails and LLM-assisted scheduling checked by deterministic rules.

  • Complex frontends

    React and Next.js interfaces for data-heavy workflows, with live status through subscriptions.

How systems survive production

Anatomy of a reliable system

Six patterns that keep an event-driven system correct when calls fail, messages repeat and traffic spikes.

  1. System diagram: Requests are acknowledged at the API and buffered in the queue; two workers drain it at their own pace.

    01 / 06

    Accept fast, process async

    The API validates the request, writes it to a durable queue and answers 202 Accepted within milliseconds. Slow or flaky work happens later, in workers that pull at their own pace. The caller’s latency no longer depends on the slowest downstream dependency.

    In practice: Return a job or event ID with the 202 so clients can poll or subscribe for the result.

  2. System diagram: A message fails twice, waits with a growing backoff and succeeds on the third attempt.

    02 / 06

    Retries with backoff

    Most failures are transient: a throttled API, a timeout, a dropped connection. A failed message is not deleted; it becomes visible again after the visibility timeout and is retried. Exponential backoff with jitter spreads the attempts, so retries don’t hit a struggling dependency as one synchronized wave.

    In practice: Keep the visibility timeout well above the worker timeout (about 6× for Lambda), or messages are redelivered mid-flight.

  3. System diagram: A message fails three times and moves to the dead-letter queue; the alarm fires and the message is redriven after a fix.

    03 / 06

    Dead-letter queue

    Some messages will never succeed: invalid data, a bug, a missing record. After maxReceiveCount attempts the queue moves the message to a dead-letter queue, so one poison message can’t block the rest or burn capacity. The failure is parked, not lost: an alarm fires, the cause is fixed, the message is redriven.

    In practice: Alarm on DLQ depth > 0. A dead-letter queue nobody watches is just a slower way to lose data.

  4. System diagram: The same message is delivered twice; the second write finds the existing key and becomes a no-op.

    04 / 06

    Idempotency

    Queues deliver at least once, and clients retry too, so the same message will eventually arrive twice. Each message carries an idempotency key; the worker records it with a conditional write and only performs the side effect if the key is new. The duplicate is absorbed, and the outcome is the same as a single delivery.

    In practice: In DynamoDB, attribute_not_exists(pk) on the key: one conditional write, no read-then-write race.

  5. System diagram: A burst fills the queue while only three worker slots run; the backlog drains at a steady rate.

    05 / 06

    Backpressure and concurrency limits

    A traffic spike is absorbed by the queue instead of being passed through. Reserved concurrency caps how many workers run at once, so the database or a partner API sees the steady load it was sized for. The backlog grows briefly, then drains: nothing is dropped, it just takes a little longer.

    In practice: Size the cap by what the downstream can handle, not by what the spike demands.

  6. System diagram: Every component emits logs and metrics; alarms watch DLQ depth and the age of the oldest message.

    06 / 06

    Observability

    Asynchronous systems fail quietly: the API keeps answering 202 while messages pile up behind it. Structured logs with a correlation ID let you follow one message across services; metrics show throughput, errors and queue depth. Alarms go on the symptoms that matter: DLQ depth and the age of the oldest message.

    In practice: Age of the oldest message catches a stuck consumer even when traffic is too low for depth to look alarming.

Case studies

Engineering stories

Problems from production systems, the trade-offs behind the solution, and what changed.

Projects

Selected projects

Production systems from my work at Formilo and ComonGames, and a few tools I built on my own.

  • Formilo, 2025–today, Main developer

    Async outreach platform

    Production platform on AWS Amplify Gen 2. It discovers companies, scrapes and AI-scores their websites, generates personalised emails and runs scheduled campaigns with live status.

    ~830 of ~920 commits

    • ~60 Lambda functions and 25 custom GraphQL mutations over 21 models
    • SQS worker pipeline with DLQ and reconciliation, processing jobs of ~3,500 websites at up to 140 concurrent workers
    • One EventBridge schedule per email, created idempotently, with a 30-minute reconciler
    • Webhook-driven external jobs with a polling fallback
    • Next.js 15
    • React 19
    • MUI
    • TanStack Query
    • AppSync
    • DynamoDB
    • Lambda
    • SQS
    • EventBridge Scheduler
    • S3
    • Cognito
  • Formilo · team project, 2025–2026, Lead developer

    Coaching Planner CRM

    Manages coaches, coachees, absences and holidays, appointment scheduling and capacity, sends timesheets and invoices by email and exports to PDF and Excel.

    ~70% of commits

    • Custom “day-first” scheduling engine: one appointment per day, at most 3 consecutive days, strict 1:1 per coach, holidays and absences respected
    • Engine covered by ~50 Vitest suites, including golden, stress and capacity tests
    • Idempotent batch-creation Lambda with a DynamoDB-based distributed lock (TransactWrite + TTL)
    • R&D extension: LLM-based scheduling as an async job (DynamoDB stream → Lambda) with OpenAI/DeepSeek providers and deterministic validation of the AI output
    • React 19
    • Vite
    • TypeScript
    • MUI
    • TanStack Query/Table
    • FullCalendar
    • Amplify Gen 2
    • Cognito
    • AppSync
    • DynamoDB
    • S3
    • Lambda
  • Client project via Formilo, 2026, Solo full-stack

    Contract-amendment workflow platform

    Release candidate

    Replaces a legacy PDF form for recording and routing contract changes at a German kitchen retailer.

    • Role-based workflow (sales, back office, admin) with hand-backs, substitutions and a full change history
    • Server-side PDF generation with Playwright: internal and customer versions, with versioning
    • Postgres-backed email outbox with retry workers and archive integration
    • Security hardening (CSRF, rate limiting, encrypted SMTP credentials), 200+ server test files, CI, Docker Compose + Caddy
    • Node.js 24
    • TypeScript
    • Express 5
    • Prisma 7
    • PostgreSQL
    • React 19
    • Vite
    • Tailwind v4
    • TanStack Query
    • Playwright
    • Docker
  • ComonGames, 2024–2026, Frontend

    Sacralium — game landing & shop

    Marketing and registration landing page for the browser MMORPG Sacralium, with sign-up and login against the game’s forum API, plus a static in-game shop with payment status pages and legal pages.

    • Containerized deployment via GitLab CI
    • HTML
    • SCSS
    • JavaScript
    • Docker
    • GitLab CI
  • Personal project, 2024–2025

    Konnektor Kompass

    Free, non-commercial trainer for German connectors and prepositions: verbs, nouns and adjectives with their prepositions.

    • Collects no personal data
    • React
    • Chakra UI
    • TanStack Query
    • Framer Motion
  • Personal project, 2026

    Medicina Legale quiz

    Exam trainer for Italian forensic-medicine questions with Russian translations, progress tracking and a review of past mistakes.

    • Versioned localStorage progress with migrations
    • Parser that turns source text into question JSON

Experience

Where I have worked

From frontend work on websites and games to full-stack systems on serverless AWS.

Berlin · open to remote

  1. – today

    Software Developer, Formilo, Berlin

    • Performant, scalable web applications with React, Next.js and TypeScript, backed by serverless AWS infrastructure.
    • Modular frontend architectures, REST API integration and responsive UI components with MUI, shadcn/ui and Chakra UI.
    • Architecture decisions, feature planning and deployment, including AI-powered features and automated workflows.
    • AWS
    • React
    • Next.js
    • TypeScript
    • Zustand
    • TanStack Query
  2. –

    Frontend Developer, ComonGames, Berlin

    • Modern frontend solutions and component-based user interfaces.
    • Close collaboration with backend and DevOps teams in agile processes.
    • Implementation and optimization of UI/UX.
    • React
    • Next.js
    • TypeScript
    • REST API
    • Material UI
    • Firebase
    • Git
    • Figma
    • WordPress
  3. –

    Frontend Developer, Adler Technologie, Berlin

    • Development and optimization of web applications, system integrations and frontend solutions.
    • Architecture meetings, code reviews and refactoring.
    • React
    • JavaScript
    • Node.js
    • Redux
    • HTML5
    • SASS
    • MySQL
    • Git
  4. –

    Frontend Developer, Forum Berufsbildung, Berlin

    • Analysis and optimization of existing websites, plus frontend and CMS tasks.
    • Technical research for shop and platform solutions.
    • JavaScript
    • WordPress
    • REST API
    • HTML5
    • CSS3
    • Figma
    • Git

Education

  • –

    Web Developer

    Tel-Ran Educational Center

  • –

    IT Specialist for Application Development (Fachinformatiker Anwendungsentwicklung)

    Forum Berufsbildung e.V.

  • –

    B.Sc. Information Systems and Information Technologies

    State University of Information Technologies, Radio Engineering and Electronics, Moscow

Languages

German
C1
Russian
Native

How I work

Principles I build by

Conclusions from my own articles. They cover the part many demos skip, which is also the part that makes a distributed system operable in production.

  1. 01

    Expect the retry

    Lambda will retry, and my architecture should be ready for it. Every handler decides on purpose which errors it throws and which it handles, and running it twice must not cause harm.

  2. 02

    Reconcile, don’t just retry

    Retries are not a replacement for reconciliation. A regular check compares what should have happened with what did, so a lost message or a missed schedule does not stay lost.

  3. 03

    Mutations coordinate workflows

    CRUD models state; mutations coordinate workflows. The browser stays responsible for intent, and the backend becomes responsible for orchestration.

  4. 04

    Real-time, with a fallback

    Real-time when it works, resilient when it doesn’t. I use subscriptions first for live status and keep polling as the fallback, so progress still arrives when a connection drops.

Contact

Let's build something reliable.

A system that has to stay up under real traffic, an idea for an article or a role to talk about: I am happy to hear from you.

Write an email

Built with Next.js 16, Tailwind CSS and CanvasHosted on VercelSource on GitHub Built