HardSystem Design

51 practiced

Design a resilient microservice architecture for real-time ability/skill processing in a hero-based game. Requirements: dynamic balancing (hotfixable), feature flags, autoscaling under bursty load, low-latency calls from game servers, and safe rollout of new ability logic. Include deployment topology and rollback strategies.

Sample Answer

**Clarify constraints**- Hard realtime: <50ms p99 from game server to ability outcome.- Hotfixable balancing, safe rollouts, support bursty spikes, per-hero variants, minimal game-server coupling.

**High-level architecture**- Game servers call a regional Gatekeeper (UDP/TCP) -> local Ability Service cluster via gRPC with low-latency. Gatekeeper does batching/aggregation when possible.- Ability Service is stateless, uses Redis/Memory cache for lookup tables, and a durable config store (Git-backed Config Service + feature-flag store like LaunchDarkly or Unleash).- Deterministic local fallback: compact balancing tables shipped with game client for offline/latency-safe deterministic simulation.

**Core components**- Ability Service: small stateless containers implementing ability logic; supports versioned logic modules (v1, v2) loaded dynamically from image or WASM plugins.- Config Service: GitOps for balance tables + feature flags; exposes hot-reload API and signed bundles.- Traffic Router: Envoy with weighted routing for canary/blue-green; circuit breakers and retry budgets.- Autoscaling: Kubernetes HPA + KEDA on request queue length and CPU; burst buffer via fast in-memory queue (Redis Streams) processed by workers.- Observability: high-cardinality metrics (latency, error, ability-id), distributed tracing, chaos tests.

**Safe rollout & rollback**- Deploy new logic as versioned WASM module or sidecar image. Use progressive rollout: 1% canary -> 5% -> 25% -> 100% based on SLOs and automated health gates (latency, correctness tests, player-facing KPIs).- Feature flags control per-region/hero toggles; kill-switch to instantly route to previous stable version.- Immediate rollback: Envoy weighted shift back to stable; invalidate new config bundle; Kubernetes rollback for failed pods.- Data migration: keep backward-compatible schemas; use dual-write / read-preference during transition.

**Resilience & low-latency tactics**- Collocate Gatekeeper in same AZ; use gRPC with protobuf, connection pooling, and sticky sessions when needed.- Cache hot balancing tables in-process; TTL with push invalidation from Config Service for hotfixes.- Deterministic client fallback for <50ms hard deadline.- Rate-limit per-game-server and use graceful degradation: simplified damage calc when overloaded.

**Operational practices**- CI pipeline runs integration tests with sampled game-scenario fuzzing and replay tests.- Runbook for hotfix: publish signed balance bundle, hot-reload, monitor, and rollback step.- Postmortems and automated rollback thresholds.

This design provides hotfixable balancing, feature-flagged safe rollouts, autoscaling for bursts, and sub-50ms tail-latency with deterministic fallbacks.

HardSystem Design

56 practiced

Design a secure achievement verification system that must accept client-reported unlocks (players may be offline) but ensure authenticity when the client reconnects. Discuss cryptographic signing, replay protection, server-side verification, and UX trade-offs for delayed verification.

Sample Answer

**Clarify requirements**- Clients may be offline when unlocking achievements; server must later accept only authentic unlocks and prevent forgery/replay.- Support cross-device accounts, low-latency UX, and occasional client tampering.

**High-level design**- Client generates an unlock proof when achievement conditions met.- Proof is signed with a client-held key and includes counters/nonces, then uploaded on reconnect.- Server verifies signature, checks freshness, and applies reward/state.

**Cryptographic signing**- Each client instance has an asymmetric keypair provisioned securely (device TPM/Keystore or per-install ECDSA key).- Proof payload: { user_id, achievement_id, timestamp, event_counter, game_version, optional gameplay-hash }.- Sign payload with private key; send { payload, signature, public_key_id }.

**Replay protection & freshness**- Include monotonic event_counter and timestamp.- Server stores highest seen (user_id, key_id) counter; reject <= highest.- Short-term server-issued nonces for sessions: when online, server can seed trusted counters.- Optional: include per-achievement random salt derived from server when available.

**Server-side verification**- Validate signature against key registry; if key unknown, perform risk checks (rate-limit, require revalidation).- Check counter > stored, timestamp within acceptable skew, and gameplay-hash matches server-side logs if available.- If suspicious, mark achievement pending and require additional evidence (replay clips, cloud-synced telemetry).

**UX trade-offs**- Instant local unlock with "locally earned" badge improves feel but must show "pending verification" state until server confirms.- Strict immediate server enforcement hurts offline play; use tiered trust: local -> pending -> verified.- For high-value rewards, require online verification before granting consumables.

**Attacks & mitigations**- Key theft: tie keys to device attestation and rotate on reauth.- Replay: counters + server highest-seen check.- Replay of legitimate proofs across users: include user_id and server-signed account binding.

**Operational notes**- Audit logs, rate-limits, and anomaly detection for farming.- Provide recovery flow: if device lost, revoke keys and allow re-verification via server-side telemetry.

This balances developer constraints: cryptographic authenticity, practical offline UX, and server-side safeguards suited for games built in Unity/Unreal.

EasyTechnical

56 practiced

You are implementing an inventory UI in Unity. Describe a design that keeps the UI responsive and consistent with the underlying model while minimizing CPU and network overhead. Mention patterns (observer, MVVM), batching updates, and how you would handle large inventories appearing/disappearing on screen.

Sample Answer

**Approach summary**Use MVVM-like separation (Model <-> ViewModel <-> View) with an observer/pub-sub layer so the UI reflects the model without polling. Keep updates batched and virtualized to minimize CPU and network work.

**Architecture**- Model: authoritative inventory state (server sync).- ViewModel: exposes observable collections and coarse-grained events (added/removed/updated ranges).- View: lightweight UI cells that bind to VM properties; cells only update when notified.

**Key patterns & techniques**- Observer / event aggregation: ViewModels publish diffs (e.g., AddRange, RemoveRange, PatchItems) instead of per-item events to avoid churn.- MVVM/data-binding: one-way binding from VM -> View; commands for user actions back to VM.- UI virtualization & pooling: reuse pooled item cells (object pool) and only instantiate cells for visible slots (infinite scroll / grid virtualization).- Batch updates & debounce: coalesce multiple model changes into single UI refresh on end-of-frame or with a short debounce (use Unity’s Update/Coroutine or Unity Main Thread dispatcher).- Canvas optimization: minimize enabled canvases, group dynamic elements, avoid frequent SetActive toggles that force rebuilds.

**Large inventories appearing/disappearing**- Virtualize content: compute visible index range and populate only those cells.- Progressive async fill: show placeholders and populate visible cells immediately; load remaining in background in small batches via coroutine to avoid frame spikes.- Smooth transitions: animate pooled cells instead of creating/destroying; use culling to skip offscreen work.

**Network & CPU minimization**- Network: send/receive deltas and authoritative diffs; request ranges for paging; compress batch updates.- CPU: avoid per-frame property checks; batch binding updates; profile canvas rebuilds and reduce layout complexity.

Result: consistent UI tied to model, low CPU spikes, and minimal network usage through diffs, batching, virtualization, and pooling.

MediumSystem Design

50 practiced

Design an achievement tracking pipeline that reduces write amplification: clients emit raw game events to an ingestion service which evaluates or forwards events to processors that award achievements. Describe buffering, batching, idempotent processors, cache-side checks, and how to ensure eventual consistency for awarded achievements.

HardTechnical

55 practiced

Define monitoring metrics, SLAs/SLOs, and an alerting strategy for inventory and leaderboard services. Include key metrics (latency, error rates, cache hit ratio, reconciliation lag), SLO targets, and the playbook for common incidents like cache stampedes or leaderboard hot shards.

Sample Answer

**Overview (role perspective)** I’d treat inventory and leaderboard as player-facing, latency-sensitive services with different access patterns: inventory is strongly consistent per player; leaderboards are read-heavy, eventually consistent, and subject to hot-shard problems.

**Key metrics to monitor**- Latency (p95/p99 read & write) — inventory reads/writes; leaderboard reads- Error rate (5xx, application-level errors) — per endpoint- Cache hit ratio — per cache tier and keyspace- Reconciliation lag — time since last background sync between primary store and read replicas/leaderboard aggregates- Throughput (req/s), CPU, memory, GC, DB connection pool- Hot-shard indicators — QPS per shard, top keys’ QPS

**SLO / SLA targets (example)**- Inventory reads: p95 < 50 ms, p99 < 150 ms, error rate < 0.1% (monthly SLO 99.9%)- Inventory writes: p95 < 100 ms, error rate < 0.5% (SLO 99.5%)- Leaderboard reads: p95 < 75 ms, p99 < 200 ms, error rate < 0.2% (SLO 99.8%)- Reconciliation lag: 95% < 5s, max < 30s

**Alerting strategy**- Severity levels: - P1 (page): SLO breach risk within 10m or errors > 1% sustained 1m, reconciliation lag > 30s, shard QPS spike > 5x baseline - P2 (email/Slack): p99 latency approaching SLO, cache hit ratio drop > 20% for 5m - P3 (ticket): non-urgent trends, capacity planning- Runbooks linked in alerts with runbook URL, owner, and rollback steps- Alert dedup and suppression windows to avoid noise during deployments

**Playbook excerpts**- Cache stampede (sudden miss storm): - Identify affected keys via metric and logs - Apply jittered exponential backoff on client; enable request coalescing / singleflight at app layer - Temporarily increase TTL for successful refreshes; pre-warm hot keys - If overwhelmed, serve degraded read from stale cache (stale-while-revalidate) and throttle background refreshes- Leaderboard hot shard: - Detect by shard QPS and top-key concentration - Immediate mitigation: route heavy keys to a dedicated in-memory shard or local cache; deploy rate-limiter for writes on top keys - Longer term: partition by hash, implement tiered aggregation (per-region partials + aggregator), or use consistent hashing with virtual nodes- Reconciliation lag / data divergence: - Pause writes to read replica consumers if possible, kick off priority sync, run consistency check on sample keys, and roll back failed aggregations - Notify product/ops if user-facing inconsistencies exceed thresholds

**Leadership & process**- Define SLO review cadence (weekly operational review, monthly SLO burn-down)- Run game-room drills for cache stampede and hot-shard incidents- Post-incident: blameless postmortem, mitigations (rate limits, partitioning, pre-warming), and update runbooks

This plan balances player experience, rapid mitigation, and engineering improvements to prevent repeat incidents.

Game Feature Implementation Gameplay Systems Questions

Sample Answer

Sample Answer

Sample Answer

Sample Answer

Sample Answer

Unlock Full Question Bank