is-BetStrike

Context

Technical challenges

• retry without losing messages — RabbitMQ won't let you modify an existing message's headers, so each retry publishes a new message with an incremented x-retry-count header; after 3 failures it's routed to the dead letter queue
• backpressure via prefetchCount — the worker only accepts the next message after acknowledging the current one, preventing it from piling up work in memory if processing slows down
• microservice communication — results, bets and payments as independent services, each with its own database
• integration without sharing a database — the FPF database (results) and the BetStrike database (bets) belong to different organisations and never access each other directly; sync always happens through integration (HTTP polling in phase 1, consuming a Kafka stream in phase 2)
• business logic in stored procedures — all database access goes through SQL Server Stored Procedures running in atomic transactions, preventing another client from bypassing validation and eliminating race conditions, like two users betting at once with the same insufficient balance
• real-time events — the AnalyticsService consumes Kafka events to generate alerts and statistics
• reproducible startup — the whole stack (databases, queues, services and frontend) comes up with a single docker compose up
• tested under load — custom stress scripts reached 30,000 bets at ~260/second with no failures; the bottleneck found was the bet-insertion stored procedure, which keeps its transaction atomic (balance, game state, insert) as a functional requirement, not a performance detail to trade away

Screenshots