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

Practice

1.

What is the primary purpose of a fine calculation system in low-level design?

easy

A. To automatically compute charges for rule violations

B. To store user personal information securely

C. To manage user login and authentication

D. To generate reports on system performance

Solution

1. Step 1: Understand the system goal

   The fine calculation system is designed to handle rule violations and compute the corresponding charges automatically.

2. Step 2: Identify the main function

   Its main function is to calculate fines based on violation details and fixed rates.

3. Final Answer:

   To automatically compute charges for rule violations -> Option A

4. Quick Check:

   Fine calculation = automatic charge computation [OK]

Hint: Focus on the system's main task: charging fines [OK]

Common Mistakes:

• Confusing fine calculation with user management
• Thinking it handles authentication
• Assuming it generates performance reports

2.

Which of the following is the correct way to represent a fine rate for a violation type in a configuration file?

violation_fine_rates = {
    'speeding': 100,
    'parking': 50,
    'signal_jump': 150
}

easy

A. Using a boolean flag for each violation

B. Using a list of fine amounts only

C. Using a dictionary with violation types as keys and fine amounts as values

D. Using a string with violation names separated by commas

Solution

1. Step 1: Analyze the data structure

   The example shows a dictionary mapping violation names to their fine amounts, which is clear and easy to update.

2. Step 2: Compare with other options

   Lists or strings do not map violation types to amounts directly, and booleans cannot store fine values.

3. Final Answer:

   Using a dictionary with violation types as keys and fine amounts as values -> Option C

4. Quick Check:

   Dictionary maps violation to fine [OK]

Hint: Use key-value pairs for clear violation-to-fine mapping [OK]

Common Mistakes:

• Using lists without keys loses violation context
• Using strings cannot store amounts
• Booleans cannot represent fine values

3.

Given the following code snippet, what will be the total fine calculated?

violation_fine_rates = {'speeding': 100, 'parking': 50}
violations = ['speeding', 'parking', 'speeding']
total_fine = sum(violation_fine_rates[v] for v in violations)
print(total_fine)

medium

A. 150

B. 200

C. 300

D. 250

Solution

1. Step 1: Calculate fine for each violation

   Violations are 'speeding', 'parking', 'speeding'. Their fines are 100, 50, and 100 respectively.

2. Step 2: Sum all fines

   Total fine = 100 + 50 + 100 = 250.

3. Final Answer:

   250 -> Option D

4. Quick Check:

   100 + 50 + 100 = 250 [OK]

Hint: Add fines for each violation in the list [OK]

Common Mistakes:

• Counting each violation only once
• Adding fines incorrectly
• Ignoring repeated violations

4.

Identify the error in the following fine calculation code snippet:

violation_fine_rates = {'speeding': 100, 'parking': 50}
violations = ['speeding', 'parking', 'signal_jump']
total_fine = sum(violation_fine_rates[v] for v in violations)
print(total_fine)

medium

A. SyntaxError due to missing colon

B. KeyError occurs because 'signal_jump' is not in the rates dictionary

C. TypeError because sum cannot add strings

D. No error, code runs fine

Solution

1. Step 1: Check dictionary keys against violations

   'signal_jump' is not a key in violation_fine_rates, so accessing it causes a KeyError.

2. Step 2: Understand error type

   Attempting to access a missing key in a dictionary raises KeyError in Python.

3. Final Answer:

   KeyError occurs because 'signal_jump' is not in the rates dictionary -> Option B

4. Quick Check:

   Missing key access = KeyError [OK]

Hint: Check if all violation keys exist in the rates dictionary [OK]

Common Mistakes:

• Assuming missing keys return zero
• Confusing KeyError with SyntaxError
• Ignoring runtime errors

5.

You are designing a fine calculation system that must support multiple violation types, each with different fine rates and possible discounts for repeat offenses. Which design approach is best?

hard

A. Use a dictionary mapping violation types to base fines and add logic to apply discounts based on offense count

B. Store all fines as a single fixed value and ignore violation types

C. Calculate fines manually each time without storing rates

D. Use a list of fines without linking to violation types

Solution

1. Step 1: Identify need for flexible fine rates

   Different violation types require different base fines, so a mapping structure is needed.

2. Step 2: Incorporate discount logic

   Discounts for repeat offenses require additional logic applied on top of base fines.

3. Step 3: Choose design approach

   A dictionary for base fines plus discount logic is clear, scalable, and easy to update.

4. Final Answer:

   Use a dictionary mapping violation types to base fines and add logic to apply discounts based on offense count -> Option A

5. Quick Check:

   Dictionary + discount logic = scalable design [OK]

Hint: Map base fines and add discount logic for repeats [OK]

Common Mistakes:

• Ignoring violation types in fine calculation
• Hardcoding fines without flexibility
• Not handling repeat offense discounts