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

Practice

1. What is the main purpose of requirements in game design?

easy

A. To describe what the game must do

B. To explain how players should play

C. To decide the game's graphics style

D. To set the game's price

Solution

1. Step 1: Understand the role of requirements

   Requirements define the features and functions the game must have to work properly.

2. Step 2: Differentiate from rules

   Rules tell players how to play, not what the game must do technically.

3. Final Answer:

   To describe what the game must do -> Option A

4. Quick Check:

   Requirements = what game must do [OK]

Hint: Requirements = what game must do, rules = how to play [OK]

Common Mistakes:

• Confusing requirements with rules
• Thinking requirements set player behavior
• Mixing technical needs with gameplay instructions

2. Which of the following is a correct way to write a game rule?

easy

A. The game must load in under 5 seconds

B. Players must collect 10 coins to win

C. Use a database to store player scores

D. The game engine should support 3D graphics

Solution

1. Step 1: Identify what a game rule is

   A game rule tells players what they must or must not do during play.

2. Step 2: Check each option

   Players must collect 10 coins to win is a player instruction (rule). Options B, C, D are technical requirements.

3. Final Answer:

   Players must collect 10 coins to win -> Option B

4. Quick Check:

   Rules = player instructions [OK]

Hint: Rules tell players what to do, not technical details [OK]

Common Mistakes:

• Confusing technical requirements with rules
• Writing rules as system features
• Ignoring player actions in rules

3. Given these statements, which one is a requirement rather than a rule?
1. Players can jump over obstacles.
2. The game must save progress automatically.
3. Players lose a life if they touch spikes.
4. The game ends after 3 levels.

medium

A. The game must save progress automatically

B. Players lose a life if they touch spikes

C. Players can jump over obstacles

D. The game ends after 3 levels

Solution

1. Step 1: Identify requirements vs rules

   Requirements describe system features; rules describe player actions and consequences.

2. Step 2: Analyze each statement

   Statement 2 is a system feature (requirement). Others describe player actions (rules).

3. Final Answer:

   The game must save progress automatically -> Option A

4. Quick Check:

   Requirement = system feature [OK]

Hint: Requirements = system features; rules = player actions [OK]

Common Mistakes:

• Mixing player actions with system features
• Choosing rules as requirements
• Ignoring automatic system behaviors

4. A game designer wrote this rule: Players must collect 5 coins to win. But players can win without coins. What is the likely problem?

medium

A. The game has too many levels

B. The requirement is missing

C. The rule is not enforced in the game logic

D. The game has a syntax error

Solution

1. Step 1: Understand the problem

   The rule says players must collect coins, but they can win without doing so.

2. Step 2: Identify cause

   This means the game logic does not enforce the rule properly.

3. Final Answer:

   The rule is not enforced in the game logic -> Option C

4. Quick Check:

   Rule enforcement = game logic implementation [OK]

Hint: If rule ignored, check game logic enforcement [OK]

Common Mistakes:

• Confusing missing requirement with rule enforcement
• Assuming syntax error causes rule failure
• Ignoring game logic role

5. You want to design a fair multiplayer game. Which combination best ensures fairness and fun?

hard

A. Flexible rules with no system requirements

B. Complex rules that confuse players and minimal system requirements

C. No rules but strict technical requirements

D. Clear rules for player actions and balanced requirements for system performance

Solution

1. Step 1: Define fairness and fun

   Fairness needs clear rules; fun needs smooth system performance (requirements).

2. Step 2: Evaluate options

   Clear rules for player actions and balanced requirements for system performance combines clear player rules and balanced system needs, ensuring fairness and fun.

3. Final Answer:

   Clear rules for player actions and balanced requirements for system performance -> Option D

4. Quick Check:

   Fairness + fun = clear rules + balanced requirements [OK]

Hint: Fair game = clear rules + balanced system needs [OK]

Common Mistakes:

• Choosing complex or missing rules
• Ignoring system performance impact
• Separating rules from requirements