The Vuch technology stack

The Vuch technology stack is the set of languages, frameworks and infrastructure on which the platform runs — published plainly because a CTO evaluating gambling infrastructure deserves specifics, not a slide of logos. The platform is an event-driven microservice architecture built around an atomic financial ledger: twelve services, one API gateway, one event bus, one source of financial truth.

The stack

Deliberately boring, in the best sense: every layer is mainstream, well-documented technology that hires easily and audits cleanly. There is no proprietary runtime an operator must take on faith, and TypeScript spans client and server, so contracts between front end and services are typed end to end.

Architecture: event-driven, ledger-centered

The platform is composed of twelve microservices behind a single API gateway, covering the domains an operator would expect — identity, markets, wallet, payments, casino, realtime, risk, content, notifications and the admin backend. Two architectural decisions define its behavior:

• The atomic financial ledger is the center. Every financial operation across both products — a prediction market trade, a casino game round, a USDT deposit or withdrawal, an admin correction — commits as an atomic entry in one ledger. Balances, admin reports, GGR analytics and risk scoring are all derived views of the same record, which is why the platform's numbers reconcile by construction rather than by overnight batch jobs.
• Events are how the platform thinks. Services communicate through a Redis-based event bus carrying 47 event types. The same stream that keeps services consistent also powers user-facing real-time features and feeds the risk engine — one backbone, three consumers.

Internal topology — service ports, routing, instance layout — is intentionally absent from this page. It belongs in technical documentation exchanged during evaluation, not on a public website.

Properties that matter to an operator

Independent horizontal scaling

Each service scales horizontally according to its own load profile. Wallet and realtime traffic — the hot paths — scale without dragging content or admin services along, and a heavy reporting day cannot crowd out transaction processing.

Durable event delivery

The event backbone uses message streams with persistent queues, so delivery is durable: events survive service restarts and consumers pick up where they left off. For a financial platform this is not an implementation detail — it is the difference between "the notification was late" and "the transaction record is incomplete."

Containerized operations with health validation

The platform runs containerized under Docker Compose with service health validation built into operations: unhealthy services are detected as such, and deployments verify the stack's state rather than assuming it. The architecture is prepared for multi-tenant deployment, which is what makes the white-label model an operational routine rather than a bespoke project.

Real-time as a first-class layer

The realtime service delivers three streams to clients over WebSocket: balance updates pushed the moment the ledger commits, a live trade feed across prediction markets, and market resolution notifications. Because these are fed by the same event bus as everything else, what a user sees live and what an administrator sees in the back office never diverge.

Data layer

PostgreSQL 15 is the primary relational store, accessed through Drizzle ORM — a typed data-access layer that keeps schema and query contracts in TypeScript alongside the services that use them. Redis plays the in-memory roles: event bus (streams and pub/sub) and cache. The division of labor is conventional and deliberate: durable financial truth in PostgreSQL, fast-moving coordination and delivery in Redis.

What this page does not claim

In keeping with how Vuch documents itself: this page makes no cloud-vendor commitments, no uptime percentage claims and no certification claims. Infrastructure behavior — scaling characteristics, failure handling, deployment layout — is demonstrated to technical evaluators against the real system, and a certification roadmap and due-diligence pack are available on request. If a claim matters to your evaluation, ask for the evidence session rather than the slide.

Where to go next

The external face of this architecture — the gateway, the REST domains, webhooks and WebSocket streams — is described in the public API overview and the integration solution. For how the architecture becomes a product, start at the platform overview. Technical teams can request a deep-dive session with our engineers, including the internal topology material this page deliberately leaves out.