Fine calculation in LLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Fine Calculation Components

Which of the following components is essential for designing a fine calculation system for a library?

A Weather API, book inventory, fine rules engine, payment gateway

B User database, book inventory, fine rules engine, payment gateway

C User database, book inventory, social media integration, payment gateway

D User database, book inventory, fine rules engine, video streaming service

💡 Hint

Think about what is needed to calculate fines and collect payments.

A fine calculation system needs to know who the user is, what books they have, the rules for fines, and a way to collect payments.

❓ Architecture

intermediate

Designing a Scalable Fine Calculation System

Which architecture best supports a fine calculation system that must handle millions of users with low latency?

A Microservices with separate services for user management, fine calculation, and payment processing

B Single server with in-memory cache for all data

C Monolithic application with a single database

D Peer-to-peer network without centralized control

💡 Hint

Consider scalability and separation of concerns.

Microservices allow independent scaling of components like fine calculation and payment processing, improving performance and maintainability.

❓ scaling

advanced

Handling Peak Load in Fine Calculation System

During peak hours, the fine calculation system experiences high traffic. Which approach best ensures system availability and responsiveness?

A Use a load balancer with auto-scaling groups for fine calculation services

B Increase the database size without changing the architecture

C Disable fine calculation temporarily during peak hours

D Use a single powerful server to handle all requests

💡 Hint

Think about distributing load and scaling dynamically.

Load balancers distribute requests evenly, and auto-scaling adds more service instances automatically to handle increased load.

❓ tradeoff

advanced

Choosing Between Real-Time and Batch Fine Calculation

What is the main tradeoff when choosing real-time fine calculation over batch processing?

A Real-time can only handle small data; batch can only handle large data

B Real-time is cheaper but less accurate; batch is expensive but always accurate

C Real-time requires no database; batch requires a database

D Real-time provides immediate feedback but requires more computing resources; batch is resource-efficient but delayed

💡 Hint

Consider speed versus resource usage.

Real-time calculation gives instant results but needs more CPU and memory; batch processing saves resources but results are delayed.

❓ estimation

expert

Estimating Storage for Fine Calculation Logs

A fine calculation system logs each fine event with 1 KB of data. If the system expects 10 million fine events per month, what is the approximate storage needed per year?

A 12 TB

B 120 TB

C 120 GB

D 1.2 TB

💡 Hint

Calculate monthly data and multiply by 12 months.

10 million events × 1 KB = 10 million KB = ~10 GB per month. For 12 months, 10 GB × 12 = 120 GB. But 10 million KB is actually about 10 GB, so 10 million KB × 12 = 120 GB. Check units carefully.

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