Requirements and game rules in LLD - System Design Exercise

Design: Game Rules Management System

In scope: rule definition, storage, versioning, retrieval, validation, and audit logging. Out of scope: game client implementation, gameplay mechanics, and user matchmaking.

Functional Requirements

FR1: Allow defining and storing game rules for different games

FR2: Support versioning of game rules to track changes over time

FR3: Enable retrieval of current and past versions of rules

FR4: Allow validation of rules to ensure they follow predefined formats

FR5: Support multiple game types with customizable rule sets

FR6: Provide an interface for game developers to update and publish rules

FR7: Ensure rules are accessible with low latency for game clients

FR8: Maintain audit logs of rule changes for accountability

Non-Functional Requirements

NFR1: Handle up to 1000 concurrent users accessing rules

NFR2: API response time for rule retrieval should be under 150ms (p99)

NFR3: System availability target of 99.9% uptime

NFR4: Support up to 10,000 rule versions per game

NFR5: Data consistency must be strong for rule updates

NFR6: Secure access with authentication and authorization

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

❓ Question 7

Key Components

API Gateway for client requests

Authentication and Authorization service

Rule Management Service for CRUD operations

Version Control module for rule versions

Validation Engine to check rule correctness

Database for storing rules and metadata

Audit Logging system

Cache layer for fast rule retrieval

Design Patterns

Event Sourcing for tracking rule changes

CQRS (Command Query Responsibility Segregation) for separating reads and writes

Versioning pattern for managing multiple rule versions

Role-Based Access Control (RBAC) for security

Cache-Aside pattern for caching rules

Reference Architecture

  +-------------------+       +-----------------------+       +----------------+
  |   Game Clients    | <---> |    API Gateway        | <---> | Auth Service   |
  +-------------------+       +-----------------------+       +----------------+
                                      |                             |
                                      v                             v
                           +-----------------------+       +----------------+
                           | Rule Management       |       | Validation     |
                           | Service               |       | Engine         |
                           +-----------------------+       +----------------+
                                      |                             |
                                      v                             v
                           +-----------------------+       +----------------+
                           | Version Control       |       | Audit Logging  |
                           | Module                |       +----------------+
                           +-----------------------+
                                      |
                                      v
                           +-----------------------+
                           | Database (Rules +      |
                           | Metadata)              |
                           +-----------------------+
                                      |
                                      v
                           +-----------------------+
                           | Cache Layer           |
                           +-----------------------+

Components

API Gateway

Nginx or AWS API Gateway

Handles incoming requests, routes them to appropriate services, and enforces rate limiting

Authentication and Authorization Service

OAuth 2.0 / OpenID Connect

Verifies user identity and permissions for accessing or modifying rules

Rule Management Service

RESTful API built with Node.js or Python Flask

Manages creation, update, deletion, and retrieval of game rules

Validation Engine

Custom validation logic or JSON Schema validators

Ensures rules conform to expected formats and constraints before saving

Version Control Module

Implemented within the service or using Git-like versioning

Tracks changes and maintains multiple versions of game rules

Database

PostgreSQL for relational data and versioning support

Stores game rules, versions, metadata, and audit logs

Audit Logging System

Elasticsearch or centralized logging service

Records all changes to rules for accountability and troubleshooting

Cache Layer

Redis or Memcached

Caches frequently accessed rules to reduce latency

Request Flow

1. 1. Game client sends a request to retrieve or update game rules via API Gateway.

2. 2. API Gateway authenticates the request with the Auth Service.

3. 3. For retrieval, the Rule Management Service first checks the Cache Layer.

4. 4. If cache miss, Rule Management Service queries the Database for the requested rule version.

5. 5. For updates, the Rule Management Service sends the new rules to the Validation Engine.

6. 6. If validation passes, the Version Control Module creates a new version entry.

7. 7. The updated rules and metadata are saved in the Database.

8. 8. Audit Logging System records the change event.

9. 9. Cache Layer is updated or invalidated to reflect the new rules.

10. 10. API Gateway returns the response to the game client.

Database Schema

Entities: - Game (game_id PK, name, description) - Rule (rule_id PK, game_id FK, content JSON, created_at, created_by) - RuleVersion (version_id PK, rule_id FK, version_number, content JSON, created_at, created_by) - User (user_id PK, username, role) - AuditLog (log_id PK, rule_id FK, version_id FK, action, timestamp, user_id FK, details) Relationships: - One Game has many Rules - One Rule has many RuleVersions - AuditLog links to Rule, RuleVersion, and User - User roles define permissions for rule operations

Scaling Discussion

Bottlenecks

Database write contention when many rule updates happen simultaneously

Cache invalidation delays causing stale rule data served to clients

Authentication service becoming a bottleneck under high concurrent requests

Validation Engine performance impacting update latency

Audit logging volume growing rapidly and affecting storage

Solutions

Use database sharding or partitioning by game to distribute write load

Implement cache invalidation with event-driven messaging for real-time updates

Scale authentication service horizontally with stateless tokens (JWT)

Optimize validation logic and consider asynchronous validation for complex rules

Archive old audit logs periodically and use scalable storage solutions like S3

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing the architecture and data flow, 10 minutes discussing scaling and trade-offs, and 5 minutes summarizing.

Clarify functional and non-functional requirements upfront

Explain choice of components and how they meet requirements

Describe how versioning and validation ensure rule integrity

Discuss caching strategy to meet latency targets

Address security with authentication and authorization

Identify bottlenecks and propose realistic scaling solutions

Show awareness of audit logging importance for accountability