Fine calculation in LLD - System Design Exercise

Design: Fine Calculation System

Design the core fine calculation logic, rule management, and API interfaces. Out of scope: payment processing, user authentication system.

Functional Requirements

FR1: Calculate fines based on different violation types (e.g., traffic, library, late payment).

FR2: Support multiple fine rules that can change over time.

FR3: Allow querying fine details for a given violation.

FR4: Provide an API to add new violations and calculate fines automatically.

FR5: Support user roles: admin (manage rules), user (view fines).

Non-Functional Requirements

NFR1: Handle up to 10,000 fine calculations per day.

NFR2: API response time p99 under 200ms.

NFR3: System availability 99.9%.

NFR4: Rules must be versioned and auditable.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Rule engine or service to evaluate fine rules

Database to store violations, rules, and fines

API layer for adding violations and querying fines

Admin interface for managing rules

Audit log for rule changes

Design Patterns

Strategy pattern for different fine calculation rules

Versioning pattern for rule updates

Caching for frequently accessed fine rules

Event-driven updates if fines depend on external events

Reference Architecture

  +-------------+       +----------------+       +-------------+
  |   Client    | <---> |   API Server   | <---> | Rule Engine |
  +-------------+       +----------------+       +-------------+
                              |                        |
                              v                        v
                       +----------------+       +--------------+
                       |   Database     |       | Audit Logger |
                       +----------------+       +--------------+

Components

API Server

Node.js or Python Flask

Handles client requests to add violations and query fines

Rule Engine

Custom service or library

Evaluates fine rules based on violation data and rule versions

Database

PostgreSQL

Stores violations, fine rules, calculated fines, and users

Audit Logger

Append-only log or database table

Tracks changes to fine rules for versioning and auditing

Request Flow

1. Client sends violation data to API Server.

2. API Server validates input and queries current fine rules from Database.

3. API Server calls Rule Engine with violation data and rules.

4. Rule Engine calculates fine amount based on rules and returns result.

5. API Server stores violation and fine details in Database.

6. API Server returns fine calculation result to Client.

7. Admin changes fine rules via API Server, which updates Database and Audit Logger.

Database Schema

Entities: - Violation(id, user_id, violation_type, violation_date, details, fine_id) - Fine(id, violation_id, amount, calculated_at) - FineRule(id, rule_type, parameters, version, effective_date, is_active) - User(id, name, role) - AuditLog(id, entity_type, entity_id, change_type, changed_by, timestamp, details) Relationships: - Violation to Fine is 1:1 - FineRule versioning tracked by version and effective_date - User roles determine access permissions

Scaling Discussion

Bottlenecks

Rule Engine performance under high request load

Database read/write contention for fine rules and violations

API Server handling concurrent requests

Solutions

Cache active fine rules in memory to reduce database reads

Use read replicas for database scaling

Deploy multiple API Server instances behind load balancer

Optimize Rule Engine with efficient algorithms and possibly precompiled rules

Use asynchronous processing for non-critical fine calculations

Interview Tips

Time: 10 minutes for requirements and clarifications, 15 minutes for architecture and data flow, 10 minutes for scaling and trade-offs, 10 minutes for questions

Clarify violation types and rule complexity

Explain rule versioning and audit requirements

Describe modular design separating API, rule engine, and storage

Discuss caching and scaling strategies

Mention trade-offs between real-time and batch fine calculation