Corporate project · Presented company-agnostic: architecture and decisions only.
Multi-tenant grading, limits and settlement workers for live sports betting
A finished game is graded, wagers are settled, batched per tenant and applied to the ledger.
Click a step to jump to it. Click a component for details.
Multi-tenant back-office and settlement engine for an online sports betting operator's live product. It grades live straight and parlay wagers when games finish, posts accounting to per-tenant Kafka streams, keeps odds integrity audits, and serves limits configuration, reporting and a Blazor administration UI.
Live betting generated a high volume of short-lived wagers that had to be graded exactly like the legacy ledger, without double-settling, across several tenants and with strict financial correctness. The legacy approach was a single, tightly coupled grading flow with no retry or dead-letter handling and little visibility into discrepancies.
01
Grading must be atomic with balance updates, so the queue lives in the same transactional store as the wagers. Kafka is used only after settlement to distribute results to tenants, where at-least-once delivery with idempotent consumers is acceptable.
02
Failing messages move off the hot path so one poison message cannot block a partition. Backoff is applied on the retry topic and permanent failures are surfaced to operators with context.
03
Single-wager messages saturated the broker at peak. Batching 50 wagers per message per tenant preserved ordering by tenant while multiplying throughput.
04
Message handlers return an explicit disposition (commit, retry, dead-letter). Permanent data errors are dead-lettered and committed, infrastructure errors retry, and a health endpoint exposes last-successful-message time so monitoring decides about restarts.
05
Aggregating settled wagers on demand was too slow. Scheduled workers recompute a rolling window to absorb late gradings, so the report API serves indexed fact tables in seconds.
06
Domain, application, infrastructure and API layers register through extension methods, and business operations return Result values instead of exceptions, keeping error mapping explicit and unit tests simple.