Katkat

Design an Extensible Tax Policy Engine

GustoSoftware Engineer · Onsite

Last updated

Design a modular, versioned tax policy engine that evaluates payroll taxes across different tax years and filing statuses using progressive and flat-rate strategies with deterministic precision.

Problem Statement

Payroll platforms must accurately calculate income taxes across varying jurisdictions, filing statuses, and changing legislative years. Previous years' payroll runs must remain 100% reproducible for auditing purposes, even as new tax rules are introduced.

Design and implement an extensible, in-memory Tax Policy Engine that:

  1. Registers Versioned Policies: Identifies policies by a unique key consisting of (tax_type, jurisdiction, tax_year, filing_status).
  2. Supports Multiple Calculation Strategies:
    • Progressive Tax: Applies a standard deduction to gross income, then evaluates taxable income across incremental tax brackets (e.g., 10% on the first $10,000, 12% on amounts above $10,000 up to $40,000).
    • Flat Rate Tax: Applies a constant percentage to gross income with no deduction.
  3. Financial Precision: Prevents floating-point drift by computing values in integer cents or exact Decimal types, rounding to two decimal places using standard half-up rounding (ROUND_HALF_UP).
  4. Reproducibility: Guarantees that passing an older tax year always evaluates using that year's specific policy without being overwritten by newer updates.

Interface

Implement the following classes and engine interface:

from decimal import Decimal
from typing import List, Tuple, Optional

class TaxBracket:
    def __init__(self, upper_limit: Optional[Decimal], rate: Decimal):
        # upper_limit: upper threshold of taxable income for this bracket (None if no cap)
        # rate: tax rate as a decimal (e.g., Decimal("0.10") for 10%)
        self.upper_limit = upper_limit
        self.rate = rate

class TaxPolicyEngine:
    def register_policy(self, policy: 'BaseTaxPolicy') -> None:
        """Registers or updates a policy definition."""
        pass

    def calculate_tax(
        self,
        tax_type: str,
        jurisdiction: str,
        filing_status: str,
        tax_year: int,
        gross_income: Decimal
    ) -> Decimal:
        """Calculates total tax due rounded to two decimal places."""
        pass

Examples

Example 1: Progressive Bracket Policy

  • Policy: tax_year=2023, filing_status="single", deduction=Decimal("5000.00")
    • Bracket 1: Up to 10000.00 at 0.10
    • Bracket 2: Over 10000.00 at 0.20
  • Input: gross_income = Decimal("25000.00")
  • Taxable Income: 25000 - 5000 = 20000
  • Computation: (10000 * 0.10) + (10000 * 0.20) = 1000 + 2000 = 3000.00
  • Output: Decimal("3000.00")

Example 2: Flat Rate Policy

  • Policy: tax_year=2024, tax_type="local_transit", rate=Decimal("0.015")
  • Input: gross_income = Decimal("80000.00")
  • Output: Decimal("1200.00")

Constraints and Edge Cases

  • gross_income >= 0. If gross_income <= deduction, taxable income is 0.00 and tax is 0.00.
  • Raise a KeyError or specific domain exception if no policy matches the requested tuple.
  • Handle brackets that extend infinitely (upper_limit=None).

Hints

Hint 1

Use the Strategy design pattern where each policy encapsulates its own calculation logic behind a common evaluate method.

Hint 2

Structure your policy registry using a tuple key like `(tax_type, jurisdiction, tax_year, filing_status)` to make lookup `O(1)` and prevent historical policy collisions.

Hint 3

Ensure all monetary inputs, rates, and calculations use Python's `Decimal` module with explicit rounding contexts rather than native binary floats.

Follow-up questions

  • How would you model policies that change mid-year (effective date ranges rather than fixed calendar years)?
  • How would you handle composite tax rules, such as when one tax deduction depends on the output of another tax calculation?
  • How would you design a dark-launch or shadow-run framework to validate that a new tax policy version matches expected outputs before rolling it out to production payroll?