Andrei Martynenko

Backend Developer specialising in Go (Golang)

Designing and building reliable, concurrency-oriented backend systems with Go.

Go-focused backend developer with a strong interest in reliability, concurrency, and performance-aware backend design. Interested in predictable system behaviour, failure handling, and building services that remain stable under load.

Projects GitHub LinkedIn Download CV

Domain-Driven Engineering Perspective

SMBC

Deutsche Bank

Alfa-Bank

Background in banking and financial systems strongly influences how I approach backend design.

Experience in regulated financial environments developed a practical awareness of:

System reliability and failure impact
Data correctness and consistency
Latency sensitivity in critical workflows
Risk, edge cases, and unexpected states

This perspective naturally translates into backend engineering, where predictability and robustness matter.

What I work on

Backend services and API-driven systems in Go
Concurrency-oriented designs (goroutines, channels, worker patterns)
Reliability-aware backend components
Performance-aware service behaviour
Data processing and integration-heavy services

Performance & Behaviour Focus

Latency

optimisation target

Reduction through timeout tuning and contention control.

Throughput

optimisation target

Improvements via bounded concurrency and simplified hot paths.

Stability

optimisation target

Backpressure, retry limits, and clearer failure semantics under spikes.

Efficiency

optimisation target

Resource efficiency via simpler hot paths and reduced retries.

What I optimize for

Typical optimisation goals in experimental systems
Latency reduction through timeout tuning and contention control
Throughput improvements via bounded concurrency
Stability improvements through backpressure and retry limits
Resource efficiency via simpler hot paths and reduced retries

Faster real-time decisions

Reduce end-to-end propagation time from event ingest to client delivery. Lower latency improves fill quality, reduces stale decisions, and makes real-time workflows usable at scale.

Typical outcomes

Consistent p99 latency targets for streaming endpoints
Less client-side polling and fewer redundant requests

Higher throughput without linear cost growth

Increase throughput by removing contention and avoiding per-request overhead on hot paths (allocations, locks, IO fan-out). Aim for predictable scaling rather than peak benchmarks.

Typical outcomes

Better utilization (CPU, memory) under sustained load
Lower infrastructure cost per request/message

Fewer incidents under load spikes

Design services to degrade gracefully: rate limiting, bulkheads, and shed non-critical work first. Keeping the system available is usually more valuable than returning every response.

Typical outcomes

Lower timeout rates during peak traffic
Clearer operational signals and faster debugging

System design examples

Conceptual examples from personal projects and active study

Concurrency (fan-in / fan-out)

goroutines + channels

Parallelize independent work, then merge results deterministically. Keep coordination explicit and bounded.

Backpressure (bounded queue)

saturation behaviour

When demand exceeds capacity, the system should respond in a controlled way instead of accumulating unbounded work.

Latency distribution (tail matters)

p95 / p99

Average latency is rarely the issue. Tail latency and queueing behaviour define user experience and reliability.

Projects

AI Sentiment Market Prediction

Real-time signal pipeline & verification-oriented system

GitHub View platform Download presentation

AI Sentiment Market Prediction platform screenshot

Problem / Focus

While the modelling components use Python/ML tooling, the project is primarily framed as a data and decision pipeline problem, focusing on:

Key engineering aspects

End-to-end latency from ingest to signal delivery
Deterministic processing stages
Clear separation of offline vs live-style workflows
Signal verification and reproducibility
Operational clarity of the pipeline

Tech stack

Go (Golang) Python ML/NLP Web UI Crypto market data Redis WebSockets Kafka

What it solves

A real-time pipeline that turns noisy external signals into a verifiable, reproducible output that can be delivered to clients with predictable latency.

FlowForge

In Progress — event-driven microservices architecture prototype in Go

Problem / Focus

Event-driven microservices architecture prototype built for learning and research purposes, exploring service boundaries, async communication, and observability-oriented design.

Key engineering aspects

gRPC service-to-service communication with a gateway layer (Envoy)
Event-driven integration via Kafka for decoupled downstream processing
Explicit ownership of data per service (Postgres, MongoDB) and caching (Redis)
Async notifications and side-effects isolated from the order hot path
Observability stack: metrics, traces, logs for debugging and capacity planning

Tech stack

Go (Golang) gRPC (foundational knowledge) Envoy Kafka / event-driven concepts PostgreSQL MongoDB Redis (basic caching patterns) OpenTelemetry Prometheus Grafana Kibana Jaeger