Lesson 05

PAM architecture — their domain

15 minutes of fluent iGaming-architecture talk and you're ahead of 90% of candidates.

1 · What is a PAM?

🧠 in plain english

Think of a casino with 4 different gambling games + a cashier's window + an ID-check counter + a security manager. PAM = the cashier's window plus the ID counter plus the security manager, all in one. Every game checks with the PAM before letting you play. PAM holds your identity, your money, your limits, your rules.

PAM = Player Account Management. The operational core of any iGaming platform:

Accounts, sessions, login
KYC tiers (light verification → full verification)
Wallet (deposits, withdrawals, balance)
Limits (daily/weekly deposit caps, self-exclusion)
Bonus engine
Compliance / audit trail

Sportsbook + casino + payment providers all plug into the PAM, not the other way round.

2 · The system diagram

               ┌────────────────────────────────────┐
               │           FRONTEND                 │
               │  Next.js · per-tenant theme · WS   │
               └──────────────┬─────────────────────┘
                              │
               ┌──────────────▼──────────────┐
               │   BFF (Next API / Nest)     │ ← auth, aggregation, WS hub
               └──────────────┬──────────────┘
                              │
           ┌──────────────────┼─────────────────────┐
           ▼                  ▼                     ▼
      ┌─────────┐       ┌──────────┐         ┌─────────────┐
      │  PAM    │◄────► │ Wallet   │ ◄─────► │  Sportsbook │
      │ accounts│       │ ledger   │         │  + casino   │
      │ KYC     │       │ idempotent│        │  vendor     │
      └────┬────┘       └─────▲────┘         └─────────────┘
           │                  │
           ▼                  │
      ┌─────────┐         ┌───┴────┐
      │compliance│        │payment │
      │ + audit  │        │ PSPs   │
      └─────────┘         └────────┘

3 · Whitelabel multi-tenancy — switch operator live

🧠 in plain english

Whitelabel = one factory, many brand stickers. The casino code is built once. Each operator (Bluestar, Redbet, Goldstrike) gets their own brand colors, currency, and rules, but the engine is identical. New operator = new config, not new code.

Click each operator below. Watch the brand color, currency, and feature visibility change. Notice how “Live Betting” is greyed out for the UK operator — that's a feature flag, not different code.

★

BLUESTAR CASINO

£ GBP

Slots

Live Casino

Live Betting

Promotions

tenant=bluestar · region=UK · liveBetting=false (regulator)

// 1. Middleware resolves tenant from host
export function middleware(req: NextRequest) {
  const host = req.headers.get("host"); // operator-a.com
  const tenant = resolveTenant(host);
  req.headers.set("x-tenant", tenant.id);
}

// 2. Theme loaded server-side, injected as CSS vars
async function RootLayout({ children, params: { tenant } }) {
  const theme = await getTenantTheme(tenant);
  return (
    <html style={{
      "--brand-primary": theme.primary,
      "--brand-radius":  theme.radius,
    } as CSSProperties}>{children}</html>
  );
}

// 3. Flags evaluated server-side per tenant + region
const flags = await flagsClient.evaluate({ tenant, user, country });
// flags = { liveBetting: false, casino: true }

{flags.liveBetting && <LiveBettingTab />}

Golden rule: configuration over code. Onboarding a new operator must require ZERO deploys. Theme + feature flags drive everything.

4 · Money operations — idempotency

🧠 in plain english

Imagine your card got double-charged at the supermarket. The cashier swiped twice because the first beep was unclear. Idempotency keys are the cashier saying “wait, I already processed transaction #ABC123. Don't charge again.” On the web: a flaky network or a double-click can submit two POSTs. Without idempotency keys, the user is charged twice.

Step through it line-by-line. Watch the BAD wallet hit $200 (overcharged), watch the GOOD wallet stay at $150 because the server stores the idempotency key and returns the cached result on retry:

Idempotency keys — wallet ops, line-by-line

step 0 / 10

1// User double-clicks 'Deposit $50' on flaky network

2// Both clicks fire requests.

4// ❌ WITHOUT idempotency

5POST /deposit { amount: 50 }

6POST /deposit { amount: 50 } // duplicate from retry/double-click

7// server has no way to detect duplicate → charges twice

9// ✅ WITH idempotency key

10const key = crypto.randomUUID(); // client generates once

11POST /deposit { amount: 50, idempotencyKey: key }

12POST /deposit { amount: 50, idempotencyKey: key } // same key

13// server stores result by key → returns cached result on duplicate

BAD wallet

$100

GOOD wallet

$100

server idempotency table

empty

network

press ▶ play to step through this code, or use ← → to scrub.

6 · Cache stampede — the senior trap

This is the question that separates seniors from mid-levels. “You have Redis caching profiles. The cache for a popular profile expires. 1000 users hit it within the same second. What happens?”

Step through the BAD path — no lock, every request hits the DB:

Cache stampede — what goes wrong without a lock

step 0 / 5

1// ❌ BAD — no lock, all misses hit DB at once

2async function getProfile(username) {

3 let data = await redis.get(`profile:${username}`);

4 if (!data) {

5 // 1000 concurrent requests all reach this branch

6 data = await db.profile.findUnique({ where: { username }});

7 await redis.set(`profile:${username}`, data, "EX", 60);

8 }

9 return data;

10}

🔴Redis

fresh

🐘Postgres

queries run

in-flight requests0

log

press ▶ play to step through this code, or use ← → to scrub.

Now the senior fix — stale-while-revalidate plus a Redis SETNX lock so only ONE request rebuilds:

SWR + SETNX lock — the senior fix

step 0 / 8

1// ✅ GOOD — stale-while-revalidate + lock

2async function getProfile(username) {

3 const cached = await redis.get(`profile:${username}`);

4 if (cached && !cached.stale) return cached.data;

6 if (cached?.stale) {

7 // serve stale immediately, refresh in background

8 refreshInBackground(username);

9 return cached.data;

10 }

12 // cold cache: try to acquire lock

13 const gotLock = await redis.set(

14 `lock:profile:${username}`, "1", "NX", "EX", 5);

16 if (gotLock) {

17 const data = await db.profile.findUnique(...); // only ONE call

18 await redis.set(`profile:${username}`, data, "EX", 60);

19 await redis.del(`lock:profile:${username}`);

20 return data;

21 }

23 // someone else is rebuilding — wait briefly + retry

24 await sleep(50);

25 return getProfile(username);

26}

🔴Redis

fresh

🐘Postgres

queries run

in-flight requests0

log

press ▶ play to step through this code, or use ← → to scrub.

📣 say this in the interview

“Client generates a UUID per operation. Server stores the result keyed on user, op, and key in a unique-indexed table. Subsequent requests with the same key return the cached result — no double-charge.”

5 · The non-negotiables for money

⚡ quick check

A user clicks 'Withdraw $500'. Network is flaky, the request times out. They click again. The server eventually receives both requests. Without idempotency, what happens?

📌 Smart questions to ask Wednesday

“Single multi-tenant codebase or per-operator deployments?”
“Feature flags — build-time, edge middleware, or runtime client?”
“Wallet ops — UUID idempotency from the client, or BFF dedup?”
“What's the SSR / RSC split for the game lobby?”
“TanStack Query, SWR, or custom cache?”
“RUM provider? How do you alert on INP regressions?”
“WebSockets vs SSE for real-time? Multiplexed or per-feature?”
“BFF — Next API routes, Nest service, or GraphQL gateway?”

PAM architecture — their domain

1 · What is a PAM?

2 · The system diagram

3 · Whitelabel multi-tenancy — switch operator live

4 · Money operations — idempotency

6 · Cache stampede — the senior trap

5 · The non-negotiables for money

Idempotency keys on every wallet mutation

Pessimistic UI for ledger ops

Audit log on every state change

Limits enforced server-side, always

Saga pattern for cross-service operations

Reconciliation jobs nightly

📌 Smart questions to ask Wednesday