“Net worth” is a simple idea: everything you own, minus everything you owe. But turning that simple idea into a live number on a phone screen is one of the harder real-time data engineering problems in consumer finance. A person’s wealth today is rarely sitting in one place. It is spread across a brokerage account holding stocks and ETFs, a 401(k) or retirement account, a couple of bank accounts, a crypto exchange wallet, a mortgage, a car loan, and maybe a manually tracked house valuation or a piece of jewelry. Each of those pieces changes value at a different speed — bank cash barely moves, stock prices move every second the market is open, crypto prices move every second of every day, and real estate value moves over months.

The idea of aggregating financial accounts into one dashboard is not new. Personal finance tools in the 2000s popularized the concept of linking bank and brokerage accounts through data aggregators, and category-defining products in the 2010s (Personal Capital, Mint, and later apps like Kubera, Empower, and Copilot) turned “net worth tracking” into a mainstream feature rather than a spreadsheet hobby. What has changed over the last decade is the expectation of the user: they no longer want a number that updates once a day after a batch job runs overnight. They want to open the app during a market swing and watch their portfolio value move in near real time, the same way they’d watch a stock ticker.

This tutorial designs that system from the ground up: a platform that continuously ingests holdings from many financial institutions and asset classes, continuously ingests live market prices, computes the value of every position, and rolls all of it up into a single, always-fresh net worth figure — pushed to the client the moment something meaningful changes, at a scale of millions of requests per minute across a large user base.

Let’s define the problem precisely before drawing any boxes.

2.1 What we are building

A platform-level system that, for any given user, can answer the question “what is my net worth right now?” in well under a second, where “right now” means the number reflects the latest known market prices and the latest known holdings, and where the number updates live on the client without the user refreshing the page.

2.2 Why This Is Hard

2.3 Functional Requirements

• Link external accounts (brokerage, bank, crypto exchange, retirement, loans) securely.
• Continuously synchronize holdings (positions, quantities, cost basis) from linked accounts.
• Continuously ingest live prices for every held instrument (equities, ETFs, crypto, forex rates).
• Support manually entered assets and liabilities (real estate, vehicles, private equity, jewelry, personal loans).
• Compute per-position market value, per-account value, per-asset-class rollups, and total net worth in the user’s chosen reporting currency.
• Push live net worth updates to connected clients (mobile app, web app) with low latency.
• Persist historical snapshots so the user can see a net worth trend line over time (day, month, year).
• Alert users on large swings or sync failures.

2.4 Non-Functional Requirements

• Scale: tens of millions of registered users, with millions of read/update requests per minute during market hours.
• Latency: a net worth read from cache should return in under 100 ms; a live push update should reach the client within 1–3 seconds of a meaningful price change.
• Consistency: eventual consistency is acceptable for market-driven valuation; strong consistency is required for the underlying holdings ledger (you cannot lose track of how many shares someone owns).
• Availability: the read path (viewing net worth) should stay available even if a downstream data aggregator or a specific institution’s API is down; degrade gracefully to “last known good value” with a staleness indicator.
• Auditability: every valuation must be traceable — which price was used, at what timestamp, from which source.

At a high level, the system is split into four planes: an ingestion plane (pulling holdings and prices in from the outside world), a computation plane (turning raw holdings and prices into valuations and rollups), a storage plane (the ledger of truth plus fast read stores), and a delivery plane (getting the number to the client quickly, and keeping it live).

3.1 Account Linking Service

Handles the OAuth or credential-exchange flow when a user connects a new institution. In practice, most platforms do not talk to thousands of banks and brokers directly; they use a financial data aggregator (a third-party service that already has connections into thousands of institutions) as a middle layer, and only build direct API integrations for the highest-volume partners (major brokerages, major crypto exchanges) where richer or faster data is worth the engineering cost.

3.2 Sync Workers

A fleet of workers responsible for pulling the actual holdings data — what does this account contain right now, and how many units of each thing does it hold. Sync workers run on a mix of triggers: webhook notifications from institutions that support them, and scheduled polling for the ones that don’t. Every successful sync writes to the Positions and Accounts DB, which is the ledger of truth for “who owns what, how much of it.”

3.3 Market Data Ingestion Service

Subscribes to live price feeds — for equities and ETFs this is typically a licensed market data vendor; for crypto this can be direct exchange WebSocket feeds; for foreign exchange, a live FX rate provider. Every tick is published onto a streaming bus (Kafka is the natural choice here) as a PriceUpdated event, keyed by instrument symbol.

3.4 Valuation Engine

A stream-processing service (built with something like Kafka Streams or Apache Flink) that is the mathematical heart of the system. It maintains an in-memory (and checkpointed) view of “which positions hold which instrument,” so that when a PriceUpdated event arrives for, say, AAPL, it can instantly recompute the market value of every position across every user that holds AAPL, without querying a database for each one.

3.5 Net Worth Aggregation Service

Consumes valuation-changed events and rolls individual position values up into account totals, asset-class totals, and a single net-worth figure per user, subtracting liabilities and converting everything into the user’s reporting currency. This service intentionally debounces and throttles — a user’s net worth does not need to be recomputed and pushed 40 times a second just because a held stock ticks 40 times a second.

3.6 Liabilities Service

Tracks debts: mortgages, auto loans, credit cards, personal loans, margin balances. Structurally very similar to the assets side, but simpler — most liabilities update on a daily statement cycle rather than a live feed, with the notable exception of margin loan balances, which can change intraday.

3.7 Currency / FX Service

Provides live foreign exchange rates so that holdings in different currencies can be normalized into one reporting currency. This is itself just another kind of “price feed” and can reuse much of the market data ingestion machinery.

3.8 Realtime Push Gateway

Maintains a persistent WebSocket (or Server-Sent Events) connection per active client and delivers net-worth updates as they are produced by the Aggregation Service. It also handles connection scaling, reconnection, and fan-out to multiple devices for the same user.

3.9 Snapshot / Time Series Store

Periodically (and after significant changes) writes an immutable snapshot of a user’s net worth to a time-series-optimized store, which powers historical trend charts (1D, 1W, 1M, 1Y, All).

The most important internal design decision in this system is this: never compute net worth by fetching live data on demand. If the system tried to call out to every linked institution and every price feed the moment a user opened the app, response times would be measured in seconds (or would fail outright when an institution’s API is slow), and the system would breach rate limits under real load. Instead, the system follows a continuously-maintained materialized view pattern: prices and holdings stream in constantly in the background, valuations are recomputed incrementally as changes arrive, and the “net worth” the user sees is simply a fast read of an already-computed, already-cached number.

4.1 Position-Centric Data Model

The core unit of the system is a Position: (user_id, account_id, instrument_id, quantity, cost_basis, as_of_timestamp). A user’s net worth is nothing more than a well-defined fold over all of their positions plus liabilities:

net_worth = Σ(position.quantity × latest_price(position.instrument) × fx_rate(instrument.currency → reporting_currency)) − Σ(liability.balance × fx_rate)

Everything the system does — ingestion, streaming, caching — exists purely to keep the two inputs to this formula (quantities and prices) fresh, and to make evaluating the formula itself cheap.

4.2 Two Independent Triggers for Recomputation

A position’s contribution to net worth can change for exactly two reasons, and the system treats them as two independent event streams that both feed the same computation:

• Holdings change — the user bought/sold shares, deposited cash, a new account was linked, a sync discovered a changed balance. This is relatively low frequency per user (a handful of times a day at most) but must be handled with strong consistency: you cannot show the wrong number of shares.
• Price change — the market moved. This is extremely high frequency for popular instruments (many ticks per second) but the computation itself is stateless and can be handled with eventual consistency: a valuation that’s one second stale is perfectly fine.

4.3 The Instrument-to-Holder Index

The single most important internal data structure in the Valuation Engine is a reverse index: instrument_id → set of position_ids that hold it. Without this index, a single price tick for a popular stock would require a full table scan to find everyone affected. With it, a price tick becomes an O(k) operation where k is the number of positions holding that instrument. This index is kept in memory (partitioned across Valuation Engine instances by instrument, so each instance only needs to hold the index for the instruments it owns) and is rebuilt incrementally as holdings events arrive.

4.4 Debouncing and Significance Thresholds

Because popular instruments can tick many times per second, the Aggregation Service does not push every single recomputation to the client. It applies two techniques together: a time-based debounce window (e.g., collapse all changes for a user into at most one push per one to two seconds), and a significance threshold (only push if the net worth changed by more than a configurable amount, e.g., 0.01% or a minimum currency amount) so that a user watching a large, mostly-cash portfolio isn’t flooded with meaningless micro-updates. Both are tunable per client (a trading-focused user might want tighter, more frequent updates than a long-term investor).

4.5 Concurrency, Data Structures, and the CAP Theorem in Practice

It is worth being explicit about which parts of this system chose availability over consistency, and which chose the opposite, because the answer is different at different layers — this system does not make one single CAP-theorem decision, it makes several, deliberately, at different boundaries.

4.5.1 Data Structures on the Hot Path

The instrument-to-holder reverse index described earlier is typically implemented as a concurrent hash map keyed by instrument symbol, where each value is a compact set (or sorted array, for cache-friendliness) of position identifiers. Two properties matter here: lookups must be O(1) average case since they happen on every single tick, and updates to the index (when a user’s holdings change) must not block ongoing reads, since a stop-the-world lock on the index would introduce latency spikes across every instrument, not just the one being updated. This is why production implementations favor lock-free or fine-grained-locking concurrent structures, or partition the index further so that updates to one instrument’s holder set never contend with lookups for a different instrument.

A second important structure is the per-user debounce timer table inside the Aggregation Service — effectively a concurrent priority queue or hashed-wheel timer keyed by user_id, used to implement the coalescing window efficiently at scale (millions of independent timers firing at different times) without the overhead of millions of individually scheduled OS-level timers.

4.5.2 Concurrency Model

The Valuation Engine is typically built as a set of single-threaded (or single-writer) partitions, one per instrument-shard, each processing its events strictly in order. This sidesteps a large class of concurrency bugs entirely: rather than using locks to protect shared mutable state across threads, each partition owns its slice of state exclusively, and parallelism comes from running many partitions concurrently rather than many threads contending over one. This “shared-nothing per partition” model is the same underlying idea that makes Kafka Streams and Flink’s keyed state model scale well, and it maps naturally onto the instrument-keyed partitioning already chosen for the price-event stream.

4.5.3 CAP Theorem Trade-offs by Component

This split is intentional and is one of the more important interview-worthy insights in this design: a single system is allowed — and often required — to make different CAP trade-offs at different internal boundaries, as long as each boundary is honest about which guarantee it is providing to the layer above it.

4.5.4 Replication, Partitioning, and Consensus

The ledger database uses leader-based replication with synchronous acknowledgment from at least one follower before a write is confirmed, using a consensus protocol (such as Raft, or a managed equivalent) under the hood to guarantee that a leader failover does not silently lose an acknowledged write. The streaming backbone (Kafka) uses its own replication and in-sync-replica quorum mechanism to guarantee that a published price or holdings event is durable before downstream consumers see it, so that a broker failure mid-processing cannot silently drop an event that a consumer has already acted on.

Partitioning, as covered in section 7, is chosen per-component to match its dominant access pattern: instrument-keyed for the price/valuation hot path, and user-keyed for the ledger and the read-facing aggregation layer. This means a single logical “net worth” computation actually crosses a partitioning boundary — from instrument-partitioned valuation data to user-partitioned aggregation — and that crossing is exactly what the PositionValuationChanged event stream in Figure 2 exists to bridge.

4.5.5 Failure Recovery

Because the Valuation Engine’s in-memory instrument index is derived state, not source-of-truth state, recovery from a crash is simple in principle: on restart, a partition reloads its holder index from the last checkpoint (periodically snapshotted state) and then replays any log entries since that checkpoint from Kafka, guaranteeing it converges to the same state it had before the crash. The same checkpoint-and-replay pattern applies to the Aggregation Service’s debounce/rollup state. This is a direct, practical application of event sourcing: because every input is an immutable, ordered, replayable log, no component needs to treat its in-memory state as precious — it can always be rebuilt.

4.6 A Worked Example: Walking Through One User’s Rollup

It helps to make the abstract formula concrete. Consider a user with a reporting currency of USD who holds: 50 shares of a stock currently priced at 200 USD in a brokerage account, 2 BTC currently priced at 60,000 USD in a linked crypto exchange account, 5,000 EUR in a European bank account, a manually entered home valued at 400,000 USD, and a mortgage liability of 250,000 USD.

The Valuation Engine independently maintains the market value of each priced position: the equity position is valued at 50 × 200 = 10,000 USD, updated every time that stock ticks; the crypto position is valued at 2 × 60,000 = 120,000 USD, updated every time that exchange’s feed ticks. Note that these two positions are, from the Valuation Engine’s point of view, completely independent — they live on different partitions (keyed by their respective instrument symbols), are updated by unrelated events, and have no awareness of each other or of the user they both belong to.

The Aggregation Service is the first point in the pipeline where these independent pieces are actually combined for this specific user. It converts the 5,000 EUR cash position using the live EUR→USD rate (say 1.08, giving 5,400 USD), takes the equity and crypto valuations as already computed, includes the manually entered home value unchanged (since it has no live feed and simply carries forward its last saved value), and sums the four asset figures: 10,000 + 120,000 + 5,400 + 400,000 = 535,400 USD in total assets. It then subtracts the 250,000 USD mortgage liability, producing a net worth of 285,400 USD.

This example also illustrates why per-position freshness matters more than a single global timestamp: if the crypto exchange’s feed is live but the user’s bank connection failed its last sync six hours ago, the correct behavior is to show 285,400 USD with a note that the cash figure is six hours stale, rather than either hiding the number entirely or presenting it as fully live when part of it isn’t.

4.7 Handling Corporate Actions and Instrument-Level Edge Cases

Public equities are not static instruments — they undergo stock splits, mergers, ticker changes, and dividend payments, all of which can silently corrupt a valuation if not modeled explicitly. A 2-for-1 stock split, for example, doubles a user’s quantity while halving the per-share price, and if the holdings-change event and the price-change event for that split are processed out of order, a user could briefly see their position value halved or doubled incorrectly. Production systems handle this with a dedicated corporate actions feed that publishes split/merger events ahead of the price change, and the Valuation Engine applies quantity adjustments atomically with the corresponding price adjustment, keyed to the same effective timestamp, so the two updates are always consumed together rather than independently racing each other. Dividends, similarly, are modeled as a cash-generating event on the linked account (increasing the cash position) rather than as any change to the equity position’s valuation itself.

It helps to walk through the full lifecycle from three different starting points: linking a new account, a normal price tick, and a user opening the app cold.

5.1 Lifecycle: Linking a New Account

This is modeled as a saga because it spans multiple systems (the OAuth provider, the token vault, the sync worker, and eventually the valuation pipeline) and any step can fail independently. A failed sync doesn’t roll back the OAuth grant; instead the account sits in an “Error” state, visible to the user, with automated retries.

5.2 Lifecycle: A Routine Price Tick (Steady State)

Covered in detail in section 4.3 and Figure 2 — this is the highest-frequency path in the system and is optimized purely for throughput and low per-event cost. It never touches a relational database on the hot path; everything needed is either in the in-memory instrument index or in the Redis valuation cache.

5.3 Lifecycle: Cold Read (User Opens the App)

1. Client authenticates and requests GET /users/{id}/net-worth.
2. API Gateway routes to the Net Worth Read Service.
3. Read Service checks the Net Worth Read Store (a fast key-value or in-memory store) for a precomputed value.
4. If present and fresh (updated within an acceptable staleness window), return immediately with a last_updated_at timestamp and a per-account freshness flag.
5. If stale beyond the threshold (e.g., an account’s last sync failed hours ago), return the last known value along with a “stale” indicator per affected account, and asynchronously trigger a re-sync — never block the user-facing read on a live upstream call.
6. Client also opens a WebSocket connection to the Realtime Push Gateway to receive subsequent live updates.

5.4 Historical Snapshotting

Independent of the live push path, the Aggregation Service writes a snapshot of net worth to a time-series store on a schedule (e.g., every 15 minutes during market hours, plus at market open/close, plus after any significant holdings change). This is deliberately decoupled from the live cache — the live cache answers “what is it right now,” the time-series store answers “how has it moved over time,” and they have very different read/write patterns and retention needs.

The unifying trade-off across nearly every decision in this system is freshness versus stability. A system that reflects every tick instantly would be technically impressive but practically useless — it would be expensive, noisy, and would make a portfolio feel more like a stock ticker than a considered wealth picture. The debounce and threshold mechanisms exist specifically to make “real-time” mean “trustworthy and current,” not “maximally twitchy.”

At the scale this system targets — tens of millions of users, market-hours traffic spiking into millions of price-driven recomputations per minute — every hot-path component must be designed to scale horizontally and to avoid hot spots.

7.1 Partitioning the Valuation Engine by Instrument

Because the reverse index (instrument → holders) is the core data structure, the natural partition key for the Valuation Engine is the instrument symbol, not the user. Kafka partitions on the price-events topic are keyed by symbol, so all ticks for AAPL always land on the same Valuation Engine instance, which can maintain that instrument’s holder index entirely in memory without needing cross-instance coordination.

7.2 Partitioning the Aggregation Service and Read Store by User

The Aggregation Service and the Net Worth Read Store, by contrast, are naturally partitioned by user_id using consistent hashing, since all rollup logic and reads are scoped to a single user at a time.

7.3 Caching Strategy

Two distinct caches serve two distinct purposes: a price cache (latest known price per instrument, extremely hot, read millions of times per minute, written on every tick) and a net-worth read cache (final computed value per user, read on every app open, written only when the debounce window fires). Both use a cache-aside pattern with a Redis cluster, but they have very different TTLs and eviction priorities — the price cache can tolerate being wrong for milliseconds; the net-worth cache should never silently expire and return nothing, since the fallback must always be “last known good value,” never “no value.”

7.4 Batching and Micro-Batching

Rather than emitting one PositionValuationChanged event per position per tick, the Valuation Engine batches changes over a small window (tens of milliseconds) before publishing, reducing the message volume the Aggregation Service has to process and dramatically cutting network and serialization overhead at peak load.

7.5 Backpressure and Load Shedding

During extreme market volatility (a crash or a sharp rally), tick volume for popular instruments can spike far above normal. The pipeline must apply backpressure gracefully: Kafka consumer lag is monitored, and if the Valuation Engine falls behind, it can degrade by widening its own internal batching window (trading a little more staleness for throughput) rather than falling over. Load shedding at the push-gateway layer — dropping to a lower-frequency update cadence for a subset of users under extreme load — is a deliberate, monitored safety valve rather than an accident.

7.6 Read Replicas and CQRS

The system deliberately separates its write model (the append-only holdings ledger and price event stream) from its read model (the precomputed net-worth cache and time-series store) — a textbook CQRS split. This means the write path can be optimized for correctness and durability, while the read path is optimized purely for speed, replicated broadly, and scaled independently.

8.1 Graceful Degradation Over Hard Failure

If the Market Data Ingestion Service loses its connection to a price provider, the system should never simply stop showing a net worth. Instead, every cached value carries a timestamp, and the client displays “as of [time]” with a subtle staleness indicator once data exceeds a threshold age. The same applies if a single linked institution’s sync is failing — that one account is flagged stale while the rest of the user’s net worth continues to update normally.

8.2 Multi-Provider Redundancy for Market Data

Relying on a single market data vendor is a single point of failure for the entire platform. Production designs typically maintain at least a secondary price feed provider that can be failed over to automatically if the primary’s latency or error rate crosses a threshold, with a circuit breaker mediating the switch.

8.3 Idempotency and Exactly-Once Effective Processing

Kafka’s delivery guarantees are at-least-once by default, meaning the same price tick or holdings-change event can be delivered more than once. Every downstream consumer is built to be idempotent — a PriceUpdated event is keyed by (instrument, timestamp), and reprocessing the same event simply overwrites the same value rather than double-counting it. The holdings ledger uses similar idempotency keys tied to the source institution’s transaction identifiers.

8.4 Disaster Recovery

The holdings ledger (the true source of “who owns what”) is the most critical piece of state in the system and is treated with database-grade durability: synchronous replication across availability zones, point-in-time recovery, and regular backup restoration drills. The valuation and net-worth caches, by contrast, are fully rebuildable from the ledger and the latest prices, so they need only best-effort durability — losing the cache is an inconvenience (a brief recomputation delay), not a data-loss event.

8.5 Consensus and Replication

The Positions and Accounts DB (the ledger) typically runs on a strongly consistent, leader-based replicated store, so that a write acknowledging “user now owns 12 shares of AAPL” is never lost or reverted. The read-optimized stores downstream can run with weaker consistency guarantees (eventual consistency across regional replicas) precisely because they are derived, not authoritative.

9.1 Credential and Token Handling

The platform should never store a user’s actual bank or brokerage login credentials. Account linking uses OAuth (or an aggregator’s tokenized link flow) so that the platform only ever holds a short-lived or revocable access token, not a password. These tokens are stored in a dedicated Token Vault — encrypted at rest with a key management service, accessible only to the Account Linking and Sync services, and never logged.

9.2 Encryption

All data in transit uses TLS, including internal service-to-service traffic. Sensitive financial data at rest — account numbers, balances, positions — is encrypted at the storage layer, with field-level encryption for the most sensitive identifiers (account numbers, tax IDs) so that even a database-level breach doesn’t expose them in plaintext.

9.3 Access Control

Internal services follow least-privilege role-based access control: the Valuation Engine, for example, needs read access to instrument holdings but has no business reading a user’s linked bank account numbers. Every internal API call carries a scoped service identity, and access to raw financial data is further gated by audit-logged, need-to-know internal tooling for support staff.

9.4 Compliance Posture

A platform handling linked financial accounts typically needs to operate under a SOC 2 Type II control framework at minimum, and depending on jurisdiction and whether it executes trades or merely aggregates data, may need to consider regulations around financial data aggregation, consumer data rights (allowing a user to fully revoke and delete linked account data), and data residency requirements.

9.5 Abuse and Fraud Considerations

Rate limiting and anomaly detection on the account-linking flow prevent credential-stuffing or token-theft attempts from being used to enumerate or scrape linked account data. Unusual patterns — a token suddenly being used from a new region, or a sudden spike in account-linking attempts from one client — are flagged for step-up authentication or automatic token revocation.

9.6 Defense in Depth Across the Pipeline

Security in this system is not a single wall around the perimeter; it is layered at every boundary the data crosses. At the ingress boundary, every external call — from a client app or from an institution’s webhook — is authenticated, validated against a strict schema, and rate limited, so that a malformed or malicious payload from a compromised partner integration cannot propagate deeper into the pipeline. Internally, service-to-service traffic uses mutual TLS so that a compromised service cannot simply impersonate another by calling its internal endpoint; combined with the least-privilege access control described above, this limits the blast radius of any single compromised component. At the data boundary, the Token Vault, the Ledger, and the audit-logging subsystem are deliberately isolated into their own security domains with tighter access controls than the general application tier, since they are the components whose compromise would be most damaging.

9.7 Handling Third-Party Aggregator Risk

Relying on a financial data aggregator for account linking introduces a trust boundary the platform does not fully control. Mitigating this risk involves minimizing the data actually persisted from the aggregator (storing only what valuation and display require, not a full copy of every transaction line item unless it’s genuinely needed), contractually and technically verifying the aggregator’s own security posture, and designing the Account Linking Service so that a full aggregator outage degrades gracefully — existing linked accounts continue to show their last-synced data — rather than becoming a hard platform-wide failure.

10.1 The Metrics That Actually Matter Here

10.2 Distributed Tracing

Every price tick and every valuation update carries a correlation ID that threads through the entire pipeline — from the Market Data Ingestion Service, through the Valuation Engine, through the Aggregation Service, to the WebSocket push. This lets an engineer trace exactly why a specific user’s update was delayed: was it consumer lag, a debounce window, or a downstream push failure.

10.3 Logging Discipline

Structured logs are used throughout, and — critically — financial values and account identifiers are never logged in plaintext in general-purpose application logs; they are only accessible through dedicated, access-controlled audit trails, separate from the operational logging pipeline used for debugging.

10.4 Alerting

Alerts are tiered: a spike in freshness lag across the whole platform pages on-call immediately; a single institution’s sync failure rate crossing a threshold generates a lower-urgency ticket, since a subset of users being briefly stale is degraded service, not an outage.

The stateless computation services — Valuation Engine, Aggregation Service, API Gateway, Realtime Push Gateway — are natural fits for containerized deployment on Kubernetes, scaled horizontally with autoscaling policies driven by custom metrics (Kafka consumer lag and active WebSocket connections, not just CPU) since those better reflect true load for a stream-processing system.

Sync Workers, which spend most of their time waiting on external institution APIs, are well suited to a worker-pool model with independent autoscaling, since their bottleneck is I/O concurrency rather than CPU.

Multi-region deployment is important for two reasons: latency (serving users from the region closest to them) and resilience (a full regional outage should not take down the platform). The holdings ledger typically has a primary region with cross-region replication for disaster recovery, while read-optimized caches and the push gateway are deployed active-active across regions, routed by geo-aware load balancing.

A blue-green or canary rollout strategy is particularly important for the Valuation Engine, since a bug in valuation logic directly produces an incorrect dollar figure shown to users — this is exactly the kind of change that benefits from a slow, metric-gated rollout rather than a full deploy.

11.1 Deployment Topology in Practice

A typical production topology separates workloads into distinct node pools tuned to their resource profile: the Valuation Engine and stream-processing tier benefit from memory-optimized nodes, since they hold large in-memory partitioned state; Sync Workers benefit from nodes tuned for high network concurrency rather than raw compute, since they spend most of their time waiting on slow external APIs; and the Realtime Push Gateway benefits from nodes tuned for a high number of concurrent open connections rather than CPU-bound work.

Configuration and secrets (API keys for market data vendors, aggregator credentials, database connection details) are managed through a centralized secrets manager rather than baked into container images or environment variables checked into source control, and infrastructure itself — the Kafka cluster sizing, the Kubernetes node pools, the database replica topology — is defined declaratively as infrastructure-as-code, so that a disaster-recovery region can be stood up predictably rather than manually.

11.2 Cost Optimization

Market data licensing and aggregator API calls are typically the largest variable cost in a system like this, which is exactly why the architecture is built around minimizing redundant external calls — caching prices in a shared layer rather than each service fetching independently, and syncing holdings on an adaptive schedule (more frequently for active traders, less frequently for dormant accounts) rather than a fixed interval for every account regardless of activity. On the compute side, autoscaling policies tied to real load signals (Kafka lag, active connections) rather than fixed always-on capacity keep infrastructure cost proportional to actual usage, particularly important given how much traffic concentrates into market-hours windows.

12.5 Load Balancing

Standard Layer 7 load balancing in front of the stateless API Gateway and REST services; for the Realtime Push Gateway, load balancing must be connection-aware — since WebSocket connections are long-lived and stateful, the load balancer needs consistent routing (or the gateway needs a shared pub/sub backbone via Redis) so that a net-worth update generated anywhere in the system can find its way to the specific gateway instance holding that user’s live connection.

The system exposes a small, clean external API surface even though a great deal of internal complexity sits behind it:

Internally, the boundaries between microservices are drawn along the lines of different rates of change and different consistency needs — Account Linking and the Ledger need strong consistency and change relatively rarely; Market Data Ingestion and the Valuation Engine are extremely high-throughput and can tolerate eventual consistency; the Aggregation Service sits in between, consuming from both. This is a deliberate application of the single-responsibility principle at the service level: each service owns exactly one axis of the net-worth formula.

Communication between services is a mix of synchronous REST/gRPC for request-response needs (like the Account Linking flow) and asynchronous event streaming for anything on the valuation hot path — a synchronous call from the Valuation Engine to the Aggregation Service for every tick would introduce coupling and latency that the architecture is specifically designed to avoid.

15.1 Best Practices

15.2 Common Mistakes

None of these products’ internal architectures are publicly documented in detail, and the design in this tutorial is a generalized, first-principles system — not a description of any specific company’s actual implementation — but the shape of the problem (federated data sources, mixed valuation models, freshness-versus-cost trade-offs) is consistent across the category.

Freshness versus stability is the unifying trade-off. Debounce and threshold mechanisms exist to make “real-time” mean “trustworthy and current,” not “maximally twitchy.”