One of a larger team on a programme decomposing a betting monolith into event-driven microservices. Design goes through reviewed decision records. I contribute to the architecture and write a share of the implementation.

• 5 000msg/s Throughput target, not measured non-functional requirement
• 100ms p99 Processing latency target, not measured non-functional requirement

system

a Kotlin / Spring Boot service that owns a core domain entity — consumes upstream events from Kafka, maintains a per-entity aggregate in PostgreSQL, and publishes the result to downstream consumers

concurrency model

ordering guarantees from partitioning rather than distributed locking, so a given aggregate is only ever touched by one thread on one instance. Stale owners after a rebalance are fenced by optimistic locking and fail-stop

delivery guarantees

transactional outbox — state and outbound events commit together, then publish at least once; consumers deduplicate on sequence numbers

Kotlin · JVM 25 · Spring Boot 4 · Kafka · Avro · PostgreSQL · jOOQ · Flyway · Testcontainers

Two Kotlin microservices ingesting an external live data feed at volume and normalising it into the internal event model — provider connectivity split from domain logic across a versioned contract.

• ≥ 200msg/s Ingestion throughput target, not measured NFR
• ≤ 50ms p95 Processing latency target, not measured NFR

system

one service owns provider connectivity and feed recovery, the other owns domain logic and persistence. The seam is a versioned message contract, so each side deploys and scales independently

recovery

the inbound stream runs through an explicit state machine with per-entity sequence tracking; any gap reverts it to a snapshot re-sync. Silent message loss becomes a self-healing transition rather than a data-quality incident found days later

Kotlin · Spring Boot 3/4 · Kafka · Avro · PostgreSQL · jOOQ · Resilience4j · Testcontainers

Took over a business-critical platform that had no active maintainer and became its main maintainer. Rewrote most of the Node.js routing application into typed TypeScript, which made the later performance and reliability work reviewable. Proposed and built the per-hop instrumentation that attributed cumulative delay to specific hops; the latency work followed from it.

• 20 000conn Concurrent WebSocket connections peak, production
• 100 000msg/s Outbound message rate fan-out to clients at peak
• tens ofms Delivery delay added by the platform at peak — was several seconds before the latency work

system

a shared real-time transport that customer-facing applications subscribe to. A Node.js / TypeScript routing application in the middle — WebSocket out to clients, ZeroMQ inward — with a client library and a publisher library as the two integration surfaces. It replaced per-team ad-hoc WebSocket solutions with one platform

storage model

it stores nothing. No broker, no replay — delivery is at-most-once and correctness comes from a sequence number on every frame. A gap triggers reconnect and snapshot re-sync, not retransmission, which removes the storage and ordering subsystem entirely

routing

hierarchical path subscriptions matched through a radix tree — one traversal resolves every prefix subscriber. The same routing model compiles into both the server and the browser client, so semantics can't drift between tiers

backpressure

bounded queues, non-blocking sends and per-connection rate limiting at the edge, so a slow or dead peer degrades locally instead of stalling the pipeline

TypeScript · Node.js · uWebSockets.js · ZeroMQ · Java 17/21 · Spring Boot · CBOR · JWT · Prometheus · Grafana · Jest · Testcontainers

The in-play section of a betting site, worked from Kafka consumer to rendered odds cell. I designed how the frontends integrate with the push platform (W-3) — subscription model, snapshot-plus-delta contract, reconnect handling — and implemented most of the backend and frontend code on that real-time path. Operated it for several years in production.

• thousands/day Live matches carried in the daily offer in-play, every day

system

a CQRS read model — a Java / Spring Boot service materialises the offer from Kafka into its own store and serves it over REST and real-time push; a React client renders odds that move several times a second. W-3 is the transport between them

high availability

shared-nothing: every instance consumes the whole stream and owns a full private copy of the data. No shared database, no leader election, no distributed lock — the failure domain is one box rather than a cluster. The cost is N× storage and N× stream consumption

client state sync

after the initial snapshot the server sends deltas, never whole objects. The client applies them over immutable structures with a version stamped per field, so a delta that arrives out of order is dropped per field instead of clobbering newer data — last-write-wins-per-field convergence without a CRDT library

Java 21 · Spring Boot 3.5 · Kafka · Avro · PostgreSQL · jOOQ · Flyway · Caffeine · TypeScript · React 18 · Immutable.js · Micrometer · Prometheus · Grafana · Testcontainers · k6

Greenfield loan and mortgage process automation for two Slovak banks — long-running approval workflows integrating core banking over SOAP. Started as a frontend developer on AngularJS and moved into the Java/Spring backend; led the loan-automation component of a .NET branch application. Also built the Android proof-of-concept for mobile onboarding with biometric verification, and an Android app for the non-profit odkazprestarostu.sk.

Java · Spring · AngularJS · .NET · SOAP · Android