Practice/Apple/Design Asset Price Management System

Design Asset Price Management System

System DesignMust

Problem Statement

Design a system that stores prices for financial assets and automatically propagates price changes through a chain of dependencies. For example, when the price of a raw material changes, all derived products whose pricing formulas reference that material must be recalculated — and their dependents must update too, cascading through a directed acyclic graph (DAG).

Think of ETF pricing (an ETF price depends on its basket of securities), supply chain cost rollups, or tax-inclusive pricing that depends on component costs. The challenge is processing these cascading updates efficiently, correctly, and without getting stuck in cycles or overwhelming the system when a widely-referenced asset changes.

Key Requirements

Functional

Asset and dependency management -- users define assets with pricing formulas and create dependency relationships forming a DAG
Price propagation -- updating a base asset's price triggers automatic recalculation of all downstream dependents
Price queries -- users can query current and historical prices for any asset with full audit trail
Propagation monitoring -- users can see propagation status and get alerted on failures or stale prices

Non-Functional

Scalability -- handle DAGs with millions of nodes where a single root change can fan out to thousands of dependents
Correctness -- every dependent must be recalculated after all its parents are updated (topological ordering)
Latency -- propagation should complete within seconds for typical graphs, minutes for worst-case fan-out
Auditability -- every price change must be traceable to its trigger, with timestamps and the formula used

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. DAG Traversal and Topological Ordering

A dependent asset cannot be recalculated until all of its parent assets have their updated prices. Processing nodes in the wrong order produces incorrect intermediate values.

Hints to consider:

Use topological sort to determine the correct processing order — nodes with no unresolved parents are processed first
Consider level-by-level BFS: all nodes at depth 1 process in parallel, then depth 2, etc.
Discuss how to detect cycles at DAG creation time (reject edges that would create a cycle)
Think about partial propagation: if one branch fails, should the rest continue or halt?

2. Handling High Fan-Out Hot Assets

Some root assets (e.g., USD exchange rate, oil price) may have thousands of direct dependents. A single price change triggers a massive burst of work.

Hints to consider:

Partition work by asset ID using a message queue so different workers process different subtrees in parallel
Use write coalescing: if the same root changes multiple times rapidly, only propagate the latest value
Implement backpressure to prevent the queue from growing unboundedly during major market movements
Consider priority queues so high-importance assets are propagated before low-priority ones

3. Idempotency and Failure Recovery

Propagation is a distributed multi-step process. Workers can crash mid-propagation, messages can be delivered twice, and network partitions happen.

Hints to consider:

Assign a unique propagation ID (version) to each root price change and carry it through all downstream updates
Each node stores the last propagation ID it processed — duplicate deliveries for the same version are safely ignored
Use durable task queues with visibility timeouts so failed tasks are retried automatically
Checkpoint progress so a crashed propagation can resume from where it left off rather than restarting

Practice/Apple/Design Asset Price Management System

Design Asset Price Management System

System DesignMust

Problem Statement

Key Requirements

Functional

Asset and dependency management -- users define assets with pricing formulas and create dependency relationships forming a DAG
Price propagation -- updating a base asset's price triggers automatic recalculation of all downstream dependents
Price queries -- users can query current and historical prices for any asset with full audit trail
Propagation monitoring -- users can see propagation status and get alerted on failures or stale prices

Non-Functional

Scalability -- handle DAGs with millions of nodes where a single root change can fan out to thousands of dependents
Correctness -- every dependent must be recalculated after all its parents are updated (topological ordering)
Latency -- propagation should complete within seconds for typical graphs, minutes for worst-case fan-out
Auditability -- every price change must be traceable to its trigger, with timestamps and the formula used

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. DAG Traversal and Topological Ordering

A dependent asset cannot be recalculated until all of its parent assets have their updated prices. Processing nodes in the wrong order produces incorrect intermediate values.

Hints to consider:

Use topological sort to determine the correct processing order — nodes with no unresolved parents are processed first
Consider level-by-level BFS: all nodes at depth 1 process in parallel, then depth 2, etc.
Discuss how to detect cycles at DAG creation time (reject edges that would create a cycle)
Think about partial propagation: if one branch fails, should the rest continue or halt?

2. Handling High Fan-Out Hot Assets

Some root assets (e.g., USD exchange rate, oil price) may have thousands of direct dependents. A single price change triggers a massive burst of work.

Hints to consider:

Partition work by asset ID using a message queue so different workers process different subtrees in parallel
Use write coalescing: if the same root changes multiple times rapidly, only propagate the latest value
Implement backpressure to prevent the queue from growing unboundedly during major market movements
Consider priority queues so high-importance assets are propagated before low-priority ones

3. Idempotency and Failure Recovery

Propagation is a distributed multi-step process. Workers can crash mid-propagation, messages can be delivered twice, and network partitions happen.

Hints to consider:

Assign a unique propagation ID (version) to each root price change and carry it through all downstream updates
Each node stores the last propagation ID it processed — duplicate deliveries for the same version are safely ignored
Use durable task queues with visibility timeouts so failed tasks are retried automatically
Checkpoint progress so a crashed propagation can resume from where it left off rather than restarting