Entry Level Backend Developer Interview Preparation Guide - FAANG Standards

Confirming the network really is the binding constraint

I wouldn't take the symptom (link saturation, rising query latency) at face value without ruling out other causes first. I'd check network interface utilization on both the app server and database side during the exact peak window, and correlate its onset with the onset of the latency increase, while also checking CPU and disk I/O on both tiers over the same window. For example: NIC (network interface) throughput at 950 Mbps sustained out of a 1 Gbps link (95% utilized), with TCP retransmissions (packets being resent because they weren't acknowledged in time, a sign the network link is congested) rising right when p99 latency (the 99th percentile response time, the slowest 1% of requests) crosses 300ms, while app server CPU sits at 40% and database CPU at 55%, both well under their own ceilings. That combination, network metric pegged and rising retransmits at the same moment latency spikes, while compute stays comfortable, is what actually confirms the network link as the binding constraint rather than assuming it from the topology alone.

Buying headroom quickly

Without touching the architecture, I'd reduce the bytes crossing that link: stop over-fetching (select only the columns actually needed instead of every column), compress payloads, batch queries to cut per-query overhead, and move some read traffic to a local cache or replica so it never has to cross the saturated link at all. These changes can ship in days and buy real headroom while a longer-term fix is planned.

The longer-term architectural fix

The quick fixes reduce load on the shared link, but the underlying issue is that traffic growth keeps colliding with a fixed-bandwidth path between two tiers that are architecturally coupled. Longer term I'd look at moving the app and database tiers onto a higher-bandwidth or lower-latency path (a dedicated link, tighter physical or network placement to cut hop count), and reducing chattiness structurally, colocating read replicas closer to the app servers, or adding a caching layer so most reads never round-trip to the database at all.

What happens next

Once the network stops being the ceiling, growth will eventually push the next resource, likely database CPU or the app tier itself, into becoming the new binding constraint. This isn't a one-time fix, it's the same identify-the-constraint exercise that needs to run again at the next growth checkpoint.

Direct answer
A team should require a formal postmortem based on explicit, pre-agreed thresholds, typically severity, measurable customer impact, an SLO or error-budget breach, or a repeated near-miss pattern, so the decision doesn't depend on ad hoc judgment calls in the moment that tend to under-count how important an incident actually was.

Structured elaboration

• Severity and customer impact are the most common triggers: any incident above a defined severity level, or any incident with measurable customer-facing impact beyond a small threshold, warrants a postmortem.
• SLO or error-budget breach is a useful objective trigger for teams that track reliability targets formally: an incident that meaningfully consumes error budget deserves review regardless of how it 'felt' in the moment.
• Repeated near-misses deserve a postmortem even without a single qualifying incident: three near-identical near-misses in a month is itself a pattern worth the same rigor as one real incident, since it's often only luck separating a near-miss from an actual outage.
• A chronically alerting or fragile component deserves a different kind of review entirely: rather than repeating a fresh, per-incident postmortem every time the same flaky component causes a small blip, a pattern-level review (is it worth rewriting, encapsulating behind a more defensive interface, or decommissioning) addresses the recurring risk directly instead of documenting the same root cause repeatedly.
• The threshold has to balance two failure modes: too low a bar drowns the team in reviews and produces fatigue and perfunctory analysis; too high a bar means real learning opportunities, especially near-misses that didn't quite become incidents, get silently skipped.

Worked example
A team defines: any Sev1 or Sev2 incident requires a full postmortem; any incident consuming more than 10% of the monthly error budget in a single event requires one regardless of severity label; three or more near-misses in the same failure category within 30 days trigger a postmortem even with no qualifying single incident; and a component causing more than five minor incidents in a quarter triggers a dedicated architectural review (rewrite, encapsulate, or decommission) rather than five separate postmortems repeating the same finding. This keeps the team from either drowning in reviews for every minor blip or missing the signal from a chronically fragile piece of infrastructure that never individually crosses the single-incident threshold.

Trade-offs and pitfalls
The most common mistake is defining thresholds purely around severity and missing the near-miss and pattern-level triggers entirely, which means a component that causes constant low-grade pain never gets the deeper, pattern-level attention it actually needs, since no single instance ever looks bad enough on its own to trigger review.

Approach — why base cases matter
Base cases/boundary conditions seed the DP table so recurrence can propagate correctly. For backend work (robust services), getting these right prevents logic bugs and off-by-one crashes in production.

(1) LCS with an empty string

• Table convention: dp[i][j] = LCS length of s1[0..i-1], s2[0..j-1].
• Base rows/cols:
  • dp[0][j] = 0 for all j (empty s1 vs prefix of s2)
  • dp[i][0] = 0 for all i (prefix of s1 vs empty s2)
• Reason: any comparison with an empty string yields length 0.

(2) Edit distance (Levenshtein) for prefixes

• Convention: dp[i][j] = min edits to convert s1[0..i-1] -> s2[0..j-1].
• Base cases:
  • dp[0][j] = j (insert j chars into empty s1)
  • dp[i][0] = i (delete i chars from s1)
• Recurrence uses dp[i-1][j-1], dp[i-1][j], dp[i][j-1].

Common off-by-one pitfalls

• Mixing index convention (0..n-1) vs lengths; forgetting dp size (n+1)x(m+1).
• Using s[i] instead of s[i-1] when i is DP index.
• Initializing dp[0][0] improperly.
• Iteration order: ensure i and j start at 1 if you rely on dp[i-1]/dp[j-1].

Minimal unit tests to catch errors

• Both empty: s1="", s2="" -> LCS=0, edit=0
• One empty: s1="", s2="abc" -> LCS=0, edit=3
• Single-char mismatch: "a" vs "b" -> LCS=0, edit=1
• Simple match: "abc" vs "abc" -> LCS=3, edit=0
• Prefix case: "abc" vs "abx" -> LCS=2, edit=1
• Different lengths: "kitten" vs "sitting" -> edit=3
• Off-by-one detector: length-1 vs length loops (e.g., s1 length 1, s2 length 0)

These tests quickly reveal wrong table sizing, wrong initialization, or indexing errors.

Direct answer

I treat it as a bounded bet rather than a leap of faith: size the learning cost against the expected payoff and how reversible adopting it would be, then run the cheapest possible probe before committing more time than that.

Structured elaboration

Sizing the bet: how many hours would it realistically take to learn enough to know if it works, versus what it could save, and is adopting it a one-way door (hard to back out of once other things depend on it) or easily reversible.

The cheap probe before committing: a strict, short timebox, often half a day, spent reproducing the actual problem I'm trying to solve and trying the new approach against it, not reading marketing material or a polished demo.

Comparing on a fixed, reproducible basis: running the same workload or test case against both the current approach and the new one, and writing down the setup and results so the comparison can be repeated later rather than relying on a vague impression of "it felt faster."

What I weigh beyond headline capability: integration cost, ongoing maintenance, and the noise it adds (a new dependency to patch, a new failure mode someone has to learn to recognize), since those often outweigh the exciting part of the pitch.

Kill criteria decided in advance: a specific condition that means I walk away, set before I start the probe, so I'm not tempted to rationalize a sunk-cost decision partway through.

Judging afterward whether it earned its place: at a set review point later, checking whether the original headline capability actually held up once it was running under real, not staged, conditions.

Worked example

I found a caching library that looked like it could fix a performance problem I was chasing. I gave myself a half-day timebox and reproduced the exact slow workload against both the current approach and the new library, writing down what I set up and what happened rather than trusting my memory of it. The result was mixed: it visibly reduced duplicate calls in the trace, but it added a dependency with thin documentation on its failure behavior. I'd decided my kill criterion in advance: if I couldn't get a reliable read on its failure modes within the timebox, I wouldn't adopt it before the deadline I was working against. I hit that limit, so I deferred adoption rather than rushing it in, but kept my notes so a future re-evaluation wouldn't start from zero.

Trade-offs and pitfalls

The most common failure here is letting the exploratory phase quietly run past its own timebox because the tool is interesting, or trusting a vendor's or blog's benchmark instead of reproducing it yourself on your own workload. The other is fixating on the headline capability and ignoring integration and maintenance cost until after you're already committed to it.

Approach
Use recursion with backtracking. A path sum is the sum of values from the root to a leaf. Because node values can be negative, I would not prune when the running sum gets too large, since later negative values could bring it back down.

def has_path_sum(root, target_sum):
    def dfs(node, remaining):
        if node is None:
            return False

        remaining -= node.val
        if node.left is None and node.right is None:
            return remaining == 0

        return dfs(node.left, remaining) or dfs(node.right, remaining)

    return dfs(root, target_sum)

Worked example
For the path 5 -> 4 -> 11 and target 20, the recursion checks 20 - 5 = 15, then 15 - 4 = 11, then 11 - 11 = 0, so it returns True.

Why backtracking is enough
Each recursive call gets its own remaining value, so there is no shared state to clean up. The function explores one root-to-leaf path at a time and stops as soon as it finds a match.

Complexity
Time is O(n) in the worst case, and space is O(h) for the recursion stack, where h is tree height.

Direct answer

A hash table stores key/value pairs so that lookup, insertion, and deletion all run in average-case
constant time, O(1), regardless of how many entries it holds. It does this by using a hash function
to convert each key into an integer, and using that integer (reduced modulo the table size) as the
index of an array where the entry lives.

Structured elaboration

The three moving parts.

• Keys are whatever you look things up by (a string, a number, a tuple of fields).
• Buckets are the slots of a fixed-size backing array. The number of buckets is the table's
  capacity.
• The hash function maps a key to an integer, and the table takes that integer modulo the
  capacity to get a bucket index. A good hash function scatters different keys roughly uniformly
  across the buckets, so no single bucket ends up disproportionately full.

Why O(1) is only an average, not a guarantee. If the hash function scatters n keys uniformly
across m buckets, each bucket holds about n/m keys on average, a small constant so long as the table
resizes to keep n/m bounded (this ratio is the load factor, covered by its own question). Looking a
key up means computing its bucket index once (O(1)) and then scanning that one small bucket, so the
whole operation is O(1) on average.

What breaks the average-case claim. The O(1) claim depends on the hash function actually
distributing keys uniformly over the keys you will actually see. It fails when:

1. The input is adversarial. An attacker who can choose the keys (e.g. form-field names, JSON
   object keys) can pick values that all hash to the same bucket, forcing every one of them into a
   single long chain, O(n) to look any of them up. This is a real, historically-exploited attack class (the mechanics and defenses are a deep topic in their own right).
2. Load factor is left unbounded. If the table never resizes as it fills up, buckets grow long
   even with an honest hash function.
3. The hash function itself is weak. A hash function with poor bit-mixing (e.g. one that only
   varies its low bits for common key patterns) can cluster "normal" keys into a few buckets even
   without any attacker.

Worked example

Take capacity m = 8 and insert three string keys using Python's built-in hashing:

# PYTHONHASHSEED=0 python3 this_file.py
# The seed is pinned ONLY so this example prints the same thing for you as it does here.
# Real deployments leave randomization ON: it is a hash-flooding defense.
keys = ["alice", "bob", "carol"]
m = 8
for k in keys:
    print(k, "-> bucket", hash(k) % m)

Output (actually run, PYTHONHASHSEED=0, reproducible across runs):

alice -> bucket 1
bob -> bucket 2
carol -> bucket 2

Note what actually happened: bob and carol both landed in bucket 2. Three keys into eight buckets collide more often than intuition suggests, and that is the point of this example rather than a flaw in it. alice is alone in bucket 1, so looking her up touches one bucket holding one entry. Looking up bob touches bucket 2, which holds two entries, so the table must compare against both. That is still O(1) on average, because the work per lookup depends on the length of ONE bucket, not on the size of the table.

If you run this without pinning the seed you will get different buckets every time, and on some runs all three keys share a bucket. If instead all three
happened to collide into the same bucket, the table would fall back to whatever collision-resolution
strategy it uses (chaining or open addressing, covered by their own question) and lookup would degrade
toward O(3) for that bucket, i.e. still fine at small n, but this is exactly the mechanism that turns
into O(n) at scale under bullet 1 or 2 above.

Trade-offs and pitfalls

A common junior mistake is to treat "hash tables are O(1)" as an unconditional fact rather than an
average-case property with named assumptions. A senior answer states the assumptions (uniform
hashing, bounded load factor, non-adversarial keys) up front and can point to at least one concrete
way each assumption can fail in production, which is exactly what separates this question from a
rote definition.

Direct answer

Analytics and business intelligence (BI) queries tolerate minutes of staleness in exchange for large latency and cost wins, so lean on materialized views and result caching aggressively, choosing the caching granularity (whole report, per-tile, per-query-result) based on how the dashboard is actually consumed.

Structured elaboration

• Materialized views: precompute and store the results of expensive aggregations on a schedule (or triggered by upstream data changes), so a dashboard read is a fast lookup against already-computed results rather than a live, expensive query against raw data.
• Result caching layers: cache the results of specific, frequently-run queries (a query-result cache keyed by the query and its parameters) for dashboards where the underlying data does not change often enough to justify a full materialized-view pipeline.
• Cache granularity: report-level caching (the whole dashboard's output) is simplest but coarse (any change forces a full recompute); tile-level (each widget/chart cached independently) allows partial invalidation when only some underlying data changed; query-result-level is the finest grain, useful when many different reports share underlying queries.
• Invalidation strategies for BI: time-to-live (TTL) is often sufficient here, since most BI use cases genuinely tolerate a bounded staleness window (minutes, sometimes hours); event-based invalidation (triggered by an upstream data-pipeline completion) is worth the added complexity specifically for dashboards where "as fresh as the last data load" matters more than a fixed time window; manual invalidation (an explicit refresh button) suits ad-hoc analysis tools where users want on-demand control.
• Cache warming/pre-computation: for dashboards viewed at predictable times (a morning operations review, a weekly business report), precomputing results just before that predictable access window avoids making the first viewer of the day pay the full, uncached computation cost.
• Balancing freshness, latency, and cost: the right TTL and caching granularity should map directly to how the business actually uses the dashboard, an operational dashboard checked continuously wants near-real-time and can justify more compute cost; a monthly strategic report tolerates hours of staleness and should be cached aggressively to save cost.

Worked example

A BI platform serving semantic-layer queries: for a query-result cache keyed by the query and its parameters, a report combining multiple underlying queries can serve most of its content from cache (queries that have not changed) while only recomputing the specific queries whose underlying data actually changed, rather than invalidating and recomputing the entire report on any single data update; this per-query granularity captures much of the tile-level caching benefit without needing the dashboard rendering layer itself to be cache-aware.

Trade-offs and pitfalls

Caching at the coarsest (whole-report) granularity for convenience, when the underlying data actually changes at different rates for different parts of the report, wastes the caching opportunity for the parts that rarely change and forces unnecessary staleness or unnecessary recomputation for the rest; choose granularity deliberately based on the actual update-rate heterogeneity within the report. Setting one TTL policy across every dashboard regardless of how it is actually used (operational versus strategic) either wastes freshness-driving compute cost where it is not needed, or under-serves freshness where it genuinely matters; tie the TTL choice to actual usage patterns.

Direct answer. EXPLAIN shows you the plan the optimizer WOULD use and its estimated costs, without running the query. EXPLAIN ANALYZE actually executes the query and reports both the estimates and the real, observed numbers (actual rows, actual time, loop counts) side by side, which is what lets you see where the optimizer's model of the data was wrong.

Structured elaboration. Because EXPLAIN alone doesn't execute anything, it is safe to run against any query, including a write query or one you suspect might be catastrophically slow, and it costs essentially nothing. EXPLAIN ANALYZE actually runs the query end to end (some databases support a dry-run or rollback mode for writes, but by default assume it executes), so it takes as long as the query itself and has the query's real side effects. You reach for EXPLAIN ANALYZE specifically when you need the actual numbers, most commonly to compare "estimated rows" against "actual rows" at each node: a large gap there is one of the single strongest signals that statistics are stale, a predicate is more selective or correlated than the optimizer assumed, or a data distribution has shifted.

Worked example. For a query that filters on created_at in the last 7 days, EXPLAIN might estimate 5,000 matching rows from an index scan. Running EXPLAIN ANALYZE against the same query might show the same index scan node actually returning 500,000 rows. That gap (5,000 estimated vs. 500,000 actual) tells you the optimizer under-costed this branch of the plan and likely chose a downstream join algorithm (say, a nested loop) that only makes sense for the small estimate, not the real volume, which is a very different diagnosis than "the index scan itself is slow."

Trade-offs and pitfalls. Running EXPLAIN ANALYZE against an expensive query in production has a real cost: it fully executes the query, so a query that would normally time out or that writes data is not safe to blindly EXPLAIN ANALYZE without thinking about it first (a SELECT read against a replica, or wrapping a write in an explicit transaction you roll back, are common ways to make this safe). It's also worth remembering that EXPLAIN ANALYZE's timing numbers include the overhead of instrumentation itself, so absolute numbers can be slightly inflated versus a bare run of the query; the RELATIVE comparison between nodes, and between estimated and actual, is what actually matters.

Situation & summary
For a backend developer designing a cloud-managed DB with millions of records and frequent inserts + range scans, pick between B-tree, skip-list, and append-only/compaction (LSM-style) by trading read/write latency, maintenance, and operational cost.

B-tree (e.g., Postgres B-tree)

• Read/write: Balanced disk-oriented tree — good random reads and reasonable writes. Inserts update tree pages; random writes and occasional page splits.
• Maintenance: Requires page splits, rebalancing, and VACUUM to reclaim space; careful WAL tuning.
• Range-scan latency: Excellent — contiguous leaf pages give low-latency sequential scans.
• Cloud suitability: Mature, predictable performance; works well for transactional workloads and cloud-managed RDBMS.

Skip-list (in-memory or on-disk variants)

• Read/write: Very fast in-memory inserts/reads (O(log n)); on-disk variants less common, random I/O cost similar to B-tree.
• Maintenance: Simpler concurrency (lock-free implementations), lower code complexity for in-memory indexes; persistence needs compaction or snapshots.
• Range-scan latency: Good for in-memory contiguous traversals; on-disk can be fragmented.
• Cloud suitability: Great for in-memory caches (Redis uses skip-list for sorted sets). Less ideal as primary durable on-disk index.

Append-only sorted logs + periodic compaction (LSM, e.g., RocksDB, LevelDB)

• Read/write: Excellent write throughput (sequential WAL and memtable flushes); write amplification from compaction.
• Maintenance: Compaction is the main cost (CPU, I/O); background compaction tunable but can cause CPU/I/O spikes and tail-latency.
• Range-scan latency: Good when data is compacted into large sorted SSTables; reads may need merging across levels causing higher point-read latency unless bloom filters and caches used.
• Cloud suitability: Excellent for high-ingest workloads, time-series, and tiered storage in cloud-managed NoSQL stores; requires operational tuning for compaction and resource isolation.

Trade-offs & recommendation

• If low-latency range scans and predictable transactional consistency are primary: B-tree.
• If write-heavy, high-throughput ingestion with acceptable compaction overhead: LSM.
• If mostly in-memory sorted sets or simple concurrency needs: skip-list.
• In cloud-managed DBs, prefer LSM for scale/write throughput (used by managed NoSQL) or B-tree for OLTP (managed RDBMS). Plan for compaction QoS, caching, and monitoring.

Direct answer

Process the iterator in fixed-size chunks and accumulate counts into a single running hash map (a Counter) that lives for the whole run, rather than ever materializing the full token sequence as a list. Peak memory becomes proportional to the chunk size plus the number of distinct tokens (not the total number of tokens processed), which is exactly what "cannot keep all tokens in memory simultaneously" requires. For scale beyond a single machine's memory even for the running counts themselves, the same idea extends outward: spill partial counts to disk or a database and merge them, or hand the aggregation to an external tool built for exactly this.

Structured elaboration

Why a single running counter, not per-chunk lists, is the key move. The chunk size controls how many raw tokens are held at once, but the thing that actually needs to survive across chunks is the aggregate count, not the raw tokens themselves. A Counter accumulated with .update(chunk) after each chunk keeps memory bounded by the chunk size (transient) plus the number of distinct tokens seen so far (persistent, but typically far smaller than the total token count for realistic text), which is the same "count of distinct values, not count of total values" property that makes hash-map-based counting memory-efficient in general.

Code patterns for the streaming read itself. In Python, this looks like iterating the source with for chunk in iterator_of_chunks: ... rather than list(iterator) up front; if the source is a file, pandas.read_csv(path, chunksize=N) or a plain line-by-line file read serves the same purpose, only ever holding one chunk in memory. The point is structural: never call an operation that forces the entire stream to materialize (a bare list(...), a sort() over the whole thing, or a pandas.concat of every chunk) before counting.

External tools for when even the running counts don't fit, or true big-data scale is needed. A few standard building blocks, worth naming by name since the question explicitly asks for external tools:

• The classic Unix pipeline sort tokens.txt | uniq -c performs exactly this kind of streaming aggregation using external (disk-backed) sort, which is how shell tooling has solved "count occurrences in a file too big for memory" for decades.
• A disk-backed key-value store (Python's shelve or dbm modules, or a lightweight embedded database like SQLite) can hold the running counts on disk instead of in a Python dict, trading memory for disk I/O when even the distinct-token count is too large to fit in RAM.
• For a genuinely distributed, multi-machine scale, a framework like Apache Spark or Dask expresses the same map-then-reduce shape (count within each partition, then merge partition-level counts) across a cluster instead of a single process's chunks.

Scoping the "at massive scale" framing honestly. For inputs that must merely avoid holding everything in memory AT ONCE on one machine (the question's actual framing), chunked accumulation into one running Counter is sufficient and is the answer worth leading with. Approximate, sub-linear-memory structures (like a Count-Min Sketch, which trades exact counts for a small, fixed memory footprint with bounded overcounting error) exist for the harder case of needing frequency estimates over a token universe too large even to enumerate distinctly, but designing such a structure is its own topic (owned by the hashing-and-hash-tables domain, not this one); it is worth naming as the next tier of solution if pressed, without building one here.

Worked example

Full runnable code with a pinned random seed and pinned parameters, comparing the chunked streaming approach against materializing the whole stream (the latter only possible here because the demo stream is deliberately small; this is exactly the comparison the chunked approach exists to avoid needing at real scale):

import random
from collections import Counter

random.seed(42)  # pinned so a reviewer re-running this gets the same stream

VOCAB = [f"tok{i}" for i in range(20)]  # small closed vocabulary for a reproducible demo


def token_stream(n_tokens):
    """Simulates a stream too large to hold in memory as a list: a generator
    that yields one token at a time, pinned by the seed above."""
    for _ in range(n_tokens):
        yield random.choice(VOCAB)


def chunked_frequency_count(stream, chunk_size):
    """Bounded-memory frequency counting: accumulate counts in a single
    running Counter (O(vocabulary size) memory, not O(stream length)),
    processing the stream in fixed-size chunks so peak memory never holds
    more than `chunk_size` raw tokens plus the running counter at once."""
    running_counts = Counter()
    chunk = []
    chunks_processed = 0
    for tok in stream:
        chunk.append(tok)
        if len(chunk) == chunk_size:
            running_counts.update(chunk)
            chunk.clear()
            chunks_processed += 1
    if chunk:
        running_counts.update(chunk)
        chunks_processed += 1
    return running_counts, chunks_processed


if __name__ == "__main__":
    n_tokens = 10_000
    chunk_size = 500

    random.seed(42)
    ground_truth = Counter(token_stream(n_tokens))

    random.seed(42)
    chunked_result, n_chunks = chunked_frequency_count(token_stream(n_tokens), chunk_size)

    print(f"n_tokens={n_tokens} chunk_size={chunk_size} chunks_processed={n_chunks}")
    print("chunked result matches ground truth:", chunked_result == ground_truth)
    print("peak resident tokens per chunk (bounded):", chunk_size, "vs full stream:", n_tokens)
    print("top 5 by frequency (chunked):", chunked_result.most_common(5))
    print("top 5 by frequency (ground truth):", ground_truth.most_common(5))

Output (actual run):

n_tokens=10000 chunk_size=500 chunks_processed=20
chunked result matches ground truth: True
peak resident tokens per chunk (bounded): 500 vs full stream: 10000
top 5 by frequency (chunked): [('tok14', 533), ('tok2', 525), ('tok4', 523), ('tok15', 523), ('tok17', 515)]
top 5 by frequency (ground truth): [('tok14', 533), ('tok2', 525), ('tok4', 523), ('tok15', 523), ('tok17', 515)]

With n_tokens=10,000 and chunk_size=500, only 20 chunks of 500 raw tokens each were ever held at once, yet the chunked result is bit-for-bit identical to counting the entire materialized stream at once (both random-seeded identically for a fair comparison), which is exactly the property that justifies using the chunked approach instead of the simpler materialize-then-count version at real scale.

Trade-offs and pitfalls

• Materializing the full stream first (list(iterator) then Counter(...)) is simpler to write and was used above only as a ground-truth cross-check; it is precisely what the question rules out, since it requires holding every token in memory at once.
• The running Counter itself still grows with the number of DISTINCT tokens seen, not the total count; if the vocabulary itself is unbounded or extremely large (arbitrary user-generated strings rather than a fixed token vocabulary), the running counter can itself become the memory bottleneck, which is exactly where spilling partial counts to disk or reaching for an approximate structure becomes necessary rather than optional.
• Choosing a chunk size is a real tuning knob: too small and the per-chunk overhead (function calls, dict updates) dominates; too large and peak memory creeps back up toward the full-stream size. The right answer depends on available memory and token size, and naming this trade-off explicitly (rather than picking an arbitrary chunk size and moving on) is part of a complete answer.
• External sort-based tools like sort | uniq -c guarantee correctness regardless of scale but at the cost of an O(n log n) sort rather than the O(n) a hash-based running count achieves; they are the right choice specifically when memory (not time) is the binding constraint, or when the tool is already part of an existing pipeline.
• Approximate structures (Count-Min Sketch and similar) trade exact counts for fixed memory and bounded error; naming that this trade-off exists is appropriate depth for this question, but designing the structure itself belongs to a different topic.