Algorithms & Problem Solving

Recognize reusable patterns and practice correctness, complexity analysis, and timed explanation.

Study routine

Explain one question without notes before revising it. Record evidence, unverified assumptions, and a next review date.

Progress: review needed → explain → solve independently → handle follow-ups.

Notes

• Problem-solving Practice Log

Problem-solving Practice Log

Pattern map

Arrays and hashing, two pointers, sliding windows, binary search, trees and graphs, heaps, backtracking, and dynamic programming.

Per-problem log

Explain without notes

1. Clarify constraints and edge cases.
2. Establish a baseline and justify improvements.
3. Explain the invariant and correctness.
4. Check empty inputs, duplicates, and large cases.
5. Record the cause of mistakes; solve from scratch next time.

Module index

System Design & Architecture Trade-offs

Start from requirements and data flow, then justify components, scale limits, and failure behavior.

Reading approach

Connect request paths, data organization, scale, and failures. Chapters directly present concepts, mechanisms, examples, and trade-offs without self-checks or hidden prose.

Notes

• Networking Essentials
• API Design
• Data Modeling
• Database Indexing
• Caching & Invalidation
• Sharding
• Consistent Hashing
• CAP & Consistency Trade-offs
• Capacity Estimation & Orders of Magnitude
• Core Concepts: Complete Topic Index

Networking Essentials

Network design determines the path a request follows, the guarantees at each layer, and the behavior under congestion, disconnection, or regional failures. Begin with one complete request, then justify protocols, connection management, and traffic distribution.

The complete path of an HTTPS request

Consider GET /training-jobs/job-42. DNS resolves the destination. If no connection can be reused, the client establishes transport and a TLS session. The HTTP request can then pass through a CDN, load balancer, application, and database before a response returns.

Separate connection setup, network round-trip time (RTT), and service processing time. Fast database work does not remove cross-continent RTT, handshake costs, or proxy queues. Connection reuse avoids repeating setup, so an HTTP request does not necessarily imply a new TCP handshake.

DNS records have caches and TTLs. Changing a record does not instantly migrate every client: failover also depends on cached addresses, existing connections, and reconnect behavior. A successful transport connection says nothing about whether a job or transaction committed.

Responsibilities by layer

Ports distinguish communication endpoints on a host. Service discovery and load balancing map a logical service onto reachable instances.

TCP, UDP, and QUIC

TCP supplies an ordered, reliable byte stream with retransmission, flow control, and congestion control. It does not preserve application message boundaries: one write can require several reads. Applications need framing through lengths, delimiters, or an upper-layer protocol. Packet loss can delay later bytes while retransmission completes.

UDP sends datagrams without built-in reliable delivery, ordering, or congestion control. It fits workloads that explicitly manage loss and timeliness, such as real-time media. Late audio can be less useful than a dropped fragment. UDP is not automatically faster once an application adds its own reliability and congestion management.

QUIC runs over UDP and adds reliable streams, encryption, and connection management. HTTP/3 uses QUIC; HTTP/1.1 and HTTP/2 commonly use TCP. Independent QUIC streams reduce transport head-of-line blocking across streams, but do not eliminate congestion or all waiting.

HTTP, TLS, and interface semantics

HTTP defines methods, status codes, headers, and bodies. HTTP/1.1 supports persistent connections, while HTTP/2 multiplexes streams. Explain which bottleneck a protocol version addresses rather than treating a version number as a performance result. MDN’s HTTP overview describes clients, servers, and intermediaries.

HTTPS protects confidentiality and integrity in transit and authenticates the server. TLS can terminate at an edge, load balancer, or application. Encrypting the separate backend hop is another deployment decision.

Encryption does not establish resource permission. An owner_id in a request body does not prove ownership. The server still validates identity, ownership, and allowed actions. HTTP’s stateless semantics also do not imply an absence of transport connections or application sessions.

REST, GraphQL, and gRPC

gRPC commonly uses Protocol Buffers and HTTP/2 and can generate multilingual clients. Binary encoding can reduce serialization costs, but end-to-end improvements depend on the workload. REST and GraphQL are interface approaches; TCP and UDP operate at a different layer.

Polling, SSE, and WebSocket

Polling repeatedly requests state. It is straightforward, at the cost of redundant requests and update delay up to a polling interval. It can be sufficient for infrequent updates.

Server-Sent Events (SSE) pushes text events through an HTTP response stream. It fits job progress, notifications, and generated text. Events can carry IDs; EventSource reconnects and can send Last-Event-ID. The application must still retain events, decide retention, and implement replay. Reconnection alone does not guarantee lossless recovery.

SSE deployments must handle proxy buffering, idle timeouts, and heartbeats. HTTP/1.1 browser connection limits may matter. See MDN’s SSE guide for event framing.

WebSocket provides a persistent, bidirectional message channel. A common HTTP/1.1 setup uses Upgrade; other HTTP versions can establish it differently. It fits frequent interaction such as collaborative actions or chat. Applications still define message types, acknowledgments, ordering, heartbeats, and recovery: TCP reliability does not cover business replay after disconnects.

WebRTC and NAT traversal

WebRTC commonly supports browser audio and video. Signaling exchanges session and connection-candidate information; the signaling service need not carry media. ICE gathers and checks candidates, STUN helps discover externally reachable addresses, and TURN relays when direct connectivity fails.

WebRTC therefore does not mean permanent peer-to-peer connectivity without servers. TURN incurs relay bandwidth costs. Multiparty systems often use selective forwarding units (SFUs), avoiding a separate outgoing media stream to every participant. MDN’s connectivity guide explains candidate exchange and connection establishment.

Load balancing requests and connections

Client-side balancing lets a library discover instances and select a target, but requires discovery, health tracking, and client-version management. Dedicated balancers centralize policy and forwarding, while introducing their own capacity and availability concerns.

L7 balancers can support WebSocket. Persistent connections do not automatically require L4. Consider Upgrade inspection, routing policy, product support, and capacity. Established connections usually remain attached to their backend, so adding instances may not redistribute existing traffic.

Round robin, least connections, weights, and consistent hashing suit different workloads. Equal connection counts do not imply equal CPU load. Passing health checks does not prove an instance has spare capacity. Sticky sessions can reduce state movement but complicate skew and recovery.

Regions and failures

A CDN reduces distance for reusable content; it cannot remove all coordination from dynamic writes. Regional services require decisions about data ownership, replication, write locations, and failover.

Timeouts bound individual waits; deadlines bound the whole operation. Retries need limits, an overall budget, backoff, and jitter. Retries at several layers amplify load. Side-effecting calls need idempotency. A circuit breaker temporarily rejects calls to a failing dependency and uses limited probes to assess recovery. AWS’s retry design article discusses these engineering choices.

For a training platform, use idempotent HTTPS requests to create jobs, resumable SSE to display progress, and a separate WebSocket channel only where frequent bidirectional interaction requires it.

Related notes and reading

API design · Caching · Estimation · Module index

Reviewed Hello Interview’s written Networking Essentials chapter through the existing authenticated session. This guide uses a request-path structure, primary documentation, and original training-platform examples; it does not transcribe course videos or quizzes.

API Design

An API contract states who may operate on which resources, how inputs are represented, what results and failures mean, and what happens when networks force retries. A training platform provides a concrete example.

Resources and operations

Identify experiments, training jobs, and checkpoints. Put resource identity in paths, optional filters in query parameters, and creation or modification data in request bodies:

POST /training-jobs
GET /training-jobs/job-42
GET /training-jobs?experiment_id=exp-7&state=running&limit=20
POST /training-jobs/job-42/cancellations

Cancellation can be represented as a request resource or an explicit RPC action. More important than naming is whether cancellation completes synchronously, is accepted for later execution, and tolerates repeated submission.

Methods and status codes

Return 201 Created for completed creation and 202 Accepted with a status location for accepted asynchronous work. 400 indicates invalid input, 401 missing valid authentication, 403 insufficient permission, 409 a state conflict, and 429 rate limiting. Stable business error identifiers supplement these categories.

Make asynchronous operations observable

Creation can return a job ID, current state, and Location. Later reads expose queued → running → succeeded/failed/cancelled. Accepted cancellation does not prove the GPU worker has stopped.

{
  "id": "job-42",
  "state": "queued",
  "attempt": 1,
  "status_url": "/training-jobs/job-42"
}

State and attempt number should come from controlled records. Failure reasons, retryability, and result locations belong in the contract rather than being inferred from logs.

Bind idempotency to the business commit

Generate an idempotency key for each logical creation and reuse it across network retries. Scope records to the caller, operation, and key, and store a request digest and outcome. Incompatible key reuse should conflict.

Atomicity matters: if creation commits before its deduplication result is saved, a crash can permit duplicate creation. A transaction can store both the idempotency record and job, with a unique constraint handling concurrent requests. Define in-progress responses, retention, and behavior after expiration.

Pagination and query cost

Offset pagination can suit stable small lists and page-number navigation. Large offsets may scan many rows, and concurrent updates can cause skips or duplicates. Cursor pagination instead records an ordering boundary:

WHERE owner_id = :owner
  AND (created_at, id) < (:last_time, :last_id)
ORDER BY created_at DESC, id DESC
LIMIT 20;

Use a unique ID to break timestamp ties. Bind cursors to filters and order. Cursor pagination alone does not guarantee a cross-page snapshot. Limit page sizes and supported query combinations; design API parameters with indexes.

Identity, permissions, and errors

Authentication establishes identity; authorization grants access to a resource or action. A valid JWT does not prove permission to read job-42. Check ownership or team permissions independently of a supplied owner_id.

Use consistent errors such as {"error":{"code":"JOB_ALREADY_TERMINAL","message":"Job cannot be cancelled"}}. Do not expose internal stacks or credentials. Rate limits may consider users, tenants, and operation costs; retry advice must respect an overall deadline.

GraphQL, gRPC, and evolution

GraphQL suits clients selecting different shapes of overlapping data. Bound query depth and cost, batch related loads, and enforce resource permissions in resolvers. One request can still cause many database queries.

gRPC expresses typed service methods and messages, fitting internal schedulers and workers. Define deadlines, cancellation, streaming, and error mapping. Binary encoding does not remove compute or database bottlenecks.

Optional additions are often easier to evolve than changed meanings, but compatibility depends on clients. Removing fields or changing sort and error semantics can break them. Version numbers do not replace deprecation and migration rules.

Related notes and source

Networking · Data modeling · Indexes · Module index

Learning reference: Hello Interview · API Design, reviewed through the authenticated written chapter. Training-job APIs, transactional deduplication, and query examples are independently organized explanations.

Data Modeling

A data model converts access patterns, business invariants, and lifecycle requirements into executable structures. Database selection, indexes, and sharding should follow from those requirements.

Start with reads, writes, and invariants

A training platform lists experiments by owner, finds recent jobs by experiment, reads successful checkpoints, and retries jobs. Its invariants include ownership, protection against stale attempts, and checkpoint publication only after complete writes.

These requirements are more precise than SQL versus NoSQL. Describe queries, sorting, filters, write frequency, and scale. Decide which constraints belong in the database and which require an application protocol.

Entities, keys, and relationships

Experiments have many jobs; jobs have many checkpoints. Membership tables can model users belonging to multiple teams. Use stable system identifiers internally rather than mutable email addresses. Natural identifiers can still have uniqueness constraints.

experiments(id PRIMARY KEY, owner_id, config_version, created_at)
jobs(id PRIMARY KEY, experiment_id, state, active_attempt, version, created_at)
job_attempts(job_id, attempt, worker_id, state, PRIMARY KEY(job_id, attempt))
checkpoints(id PRIMARY KEY, job_id, attempt, step, object_key, state)

Separating logical jobs from execution attempts preserves retry history. Real schemas also need foreign keys, non-null constraints, and appropriate uniqueness rather than relying on every caller to enforce rules.

What different models change

A product category does not establish its exact transaction or consistency guarantees. Specify the operations and guarantees of the actual system.

Normalization and denormalization

Normalization reduces duplication and update anomalies. Denormalization can improve a proven access path, such as storing a latest-job summary with an experiment.

For duplicated views identify the source of truth, update mechanism, and repair process. Asynchronous materialized views reduce read cost but introduce visibility delay and rebuilding. A historical submission-time configuration can be an intentional business fact rather than erroneous duplication.

Protect concurrent state changes

ACID consistency does not guarantee that every concurrent execution matches application intent. Isolation levels, locks, and conditional writes determine observable behavior. PostgreSQL’s isolation documentation distinguishes these guarantees.

UPDATE jobs
SET state = 'running', version = version + 1
WHERE id = :job_id AND state = 'queued' AND version = :expected_version;

Zero updated rows means the record changed, not that acquisition succeeded. Completion should verify attempt numbers or fencing tokens so an expired worker cannot overwrite a newer execution.

Large objects and publication boundaries

Keep weights, archived logs, and datasets in object storage; record locations, sizes, checksums, versions, and publication state in metadata. Object storage and a database generally do not share a local transaction.

One approach writes to a unique temporary location, validates the object, and then commits availability. Garbage collection removes abandoned objects. Readers consume only published records. Versioning, attempt IDs, and idempotent publication help prevent overwrites and duplicate registrations.

Access paths and lifecycle

An index on (experiment_id, created_at, id) supports recent experiment jobs. Owner-wide queries may require another access path. Sharding by experiment preserves locality but can create a hotspot for a huge experiment.

Retention, archives, logical deletion, physical deletion, and audit records affect the schema. Logical deletion does not reclaim storage. Database and object cleanup require retryable workflows and clear retention boundaries.

Related notes and source

Indexes · Sharding · CAP · RL systems

Learning reference: Hello Interview · Data Modeling, reviewed through the authenticated written chapter. The jobs, attempts, and checkpoints model is an independent example.

Database Indexing

An index is an additional maintained access path. It can reduce examined records, accessed pages, and sorting, while consuming storage, cache, and write resources. Begin with a concrete query rather than indexing every field.

Pages, scans, and selectivity

Tables are organized into pages processed in memory. An index narrows candidate records before necessary table access. Cache hits, sequential access, and random access differ, so one logical lookup does not imply one physical disk operation.

When a query returns much of a table, a sequential scan can beat many index-directed table fetches. Optimizers consider selectivity, statistics, distribution, and estimated costs.

B-trees and composite order

B-trees maintain ordered branching structures for equality, ranges, and ordering. Small tree height alone does not determine latency: caching, table fetches, and result count still matter.

CREATE INDEX jobs_by_experiment_recent
ON jobs (experiment_id, created_at DESC, id DESC);

SELECT id, state, created_at
FROM jobs
WHERE experiment_id = 42
ORDER BY created_at DESC, id DESC
LIMIT 20;

This index locates an experiment and follows the requested order. Time-only filtering is a different access path. Choose order from equality, range, ordering, and real distribution, not a universal “most selective first” rule. Some engines support skip-scan optimizations, so left-prefix limitations should not be stated as absolute for every implementation.

Covering, partial, and expression indexes

Covering indexes include returned fields and can reduce table access. PostgreSQL’s INCLUDE (state) adds a payload column, but efficient index-only scans also depend on visibility information.

Partial indexes retain a qualifying subset, such as active jobs, and require compatible query predicates. Expression indexes can support lower(email); a normal index does not automatically accelerate arbitrary expressions. See PostgreSQL’s index documentation.

LSM writes and compaction

LSM engines typically record writes in a WAL and memory structure before flushing sorted files. Compaction merges files and obsolete versions; exact ordering and durability depend on the implementation and configuration.

Batching can replace some random updates, but reads may inspect several files or levels. Bloom filters skip files that cannot contain a key. Compaction consumes background resources. Compare read, write, and space amplification and tail latency rather than calling B-trees read-only or LSM write-only.

Specialized structures

Geohash encodes spatial cells, but nearby locations can cross boundaries, requiring neighboring cells. Quadtrees recursively divide space; R-tree families organize bounding regions. PostGIS can use GiST-based indexes. Separate ordinary latitude and longitude indexes do not automatically make radius searches efficient.

Write and maintenance costs

Inserts, updates, and deletes can maintain several indexes, adding logs, cache pressure, and storage. Wide frequently changed covering fields can be costly. Unique indexes also enforce constraints and cannot be removed based solely on read usage.

Observe use and maintenance costs instead of prescribing a fixed maximum index count. Online creation must consider locking, extra space, and cleanup after failures.

Verify execution

EXPLAIN displays a plan. EXPLAIN ANALYZE actually executes the statement, so writes and expensive queries are not harmless inspections.

Check scans, estimated versus actual rows, filtered rows, sorts, temporary files, cache hits, and physical reads. Large estimate errors suggest statistics or skew problems. A faster individual query does not prove better overall performance under writes or cold caches.

Related notes and source

API queries · Data models · Caching · Sharding

Learning reference: Hello Interview · Database Indexing, reviewed through the authenticated written chapter. This guide is independently organized around execution and maintenance costs.

Caching and Invalidation

Caches retain reusable data or computation results. They trade storage and consistency complexity for lower latency and less backend work. Start with a measured bottleneck and acceptable freshness, rather than adding Redis by habit.

Placement changes the cost

Public documents, personalized responses, and private logs cannot blindly share keys. Keys may need tenant, version, parameters, or permission scope in addition to a resource ID.

Read and write responsibilities

Cache-aside makes the application check the cache, load misses, and populate results. Read-through delegates loading to a cache layer or wrapper. These are responsibility boundaries, not interchangeable Redis commands.

Write-through synchronously reaches durable storage before acknowledging completion. Write-back acknowledges cached writes and flushes later, exposing a durability window. Two independent application writes do not automatically form an atomic write-through protocol.

Expiration versus eviction

TTL specifies expiration; eviction selects entries under memory pressure. LRU favors recent use, LFU frequent use, and FIFO insertion order. Implementations can be approximate.

Choose based on hotspot duration, scans, and object sizes. TTL is not automatically a freshness bound measured from a business update: stale readers may populate old values later and restart expiration. See Redis’s eviction reference.

Database updates and invalidation

A common cache-aside pattern commits the database and deletes the cache entry. This does not create a cross-system transaction.

A reader can load old data, another request can update the database and invalidate, and the original reader can then repopulate the stale value. Depending on required guarantees, consider versioned keys, conditional fills, change-driven invalidation, or coordinated reads and writes. Define compensation when invalidation fails and the role of TTL.

Caches should not make unverified final decisions about exact quotas or inventory. Display data tolerating seconds of staleness may need a simpler protocol.

Failure modes

Direct database fallback is safe only if the database has sufficient headroom.

From hit rate to backend demand

At 12,000 reads/s and a 95% request hit rate, ideal steady-state origin demand is about 600 reads/s. A cache outage can drive it toward 12,000 reads/s. This excludes request merging, multikey requests, and refreshes.

High average hit rates can hide slow misses. Track request and byte hit rates, origin traffic, p95/p99, eviction, memory, and skew. System p99 is not a weighted average of hit and miss p99 values.

Training-platform choices

Immutable terminal-job summaries, versioned configurations, and public model descriptions are good candidates. Active progress needs an explicit refresh policy. Recovery and quota allocation rely on controlled state. Attempt IDs in keys separate retries; generation timestamps help distinguish old data during display and debugging.

Related notes and source

Data modeling · Consistency · Estimation

Learning reference: Hello Interview · Caching, reviewed through the authenticated written chapter. The explanation is independently organized around freshness, races, and failure traffic.

Sharding

Sharding distributes a logical dataset across machines to expand capacity or share load. It changes query, transaction, migration, and operational boundaries, not merely the routing formula.

Partitioning, sharding, and replication

Single-instance partitioning creates smaller management units and can help pruning, archiving, and maintenance without adding machines. Sharding usually puts subsets on different machines. Replication copies the same data for resilience or supported read scaling.

They can coexist: shards have replicas and databases can have internal partitions. Read replicas do not automatically remove a primary write hotspot.

Establish a constraint first

Determine whether storage, IO, CPU, logging, locks, or one hot object limits the system. Query and index changes, pooling, batching, larger machines, caching, or read replicas may suffice.

Shard when expected load, growth, recovery time, or geographic requirements justify it. No universal GB or QPS threshold applies. Backup and restore duration can matter even before throughput is exhausted.

Choose a key, then a placement rule

A shard key determines the ownership unit. Good keys spread data and activity while keeping frequent operations local. High cardinality alone does not guarantee balanced traffic.

AWS’s partition-key guidance emphasizes activity distribution, not only record counts.

Change the unit of a hotspot

If one experiment generates half the writes, hashing its ID still selects one destination. Splitting logs by (experiment_id, time_bucket, subshard) creates independently routable write units.

Reads then need multiple shards and merging. Query clients must discover bucket boundaries and subshard counts. Random suffixes without a read plan merely move the bottleneck.

Cross-shard queries and transactions

Fan-out queries aggregate partial results. Global recent-20 queries can merge local candidates, but deep pagination, filters, and unavailable shards complicate semantics. Separate secondary indexes add visibility and consistency questions.

Distributed commit can coordinate transactions, or data ownership can keep critical invariants local. Compensating workflows such as sagas do not equal one atomic transaction. Globally unique IDs do not establish every business uniqueness constraint.

Online expansion is a protocol

One migration approach prepares a target, copies a snapshot, catches up incremental changes, validates, switches routing versions, retains a rollback window, and eventually removes old copies. Define read and write ownership at every stage.

Copy-then-switch can miss concurrent writes. Uncoordinated dual writes can succeed on only one side. Account for duplication, ordering, tombstones, and stale routes, using versions or routing epochs to constrain old owners.

Managed systems still need modeling

A database may automate physical splits and balancing, but it cannot choose the right application access unit. Hot keys, cross-partition transactions, and secondary indexes remain important. Different managed systems do not necessarily use the same hash-ring placement algorithm; rely on their documented mechanisms.

Related notes and source

Data models · Consistent hashing · CAP · Estimation

Learning reference: Hello Interview · Sharding, reviewed through the authenticated written chapter. The migration reasoning and training-log example are independently developed.

Consistent Hashing

Consistent hashing reduces key reassignment when cluster membership changes. It is a placement and routing method, not a protocol for replica agreement, durability, or recovery.

Why direct modulo complicates expansion

For a fixed cluster, hash(key) % N is simple. Changing N to N+1 remaps many keys. Caches can experience widespread misses; persistent stores need movement and compatibility with old locations.

The issue is coupling ownership directly to physical node count, not modulo itself. Fixed logical partitions mapped separately to machines provide another way to reduce that coupling.

Ring ownership

Place keys and nodes in a circular hash space. A common rule assigns a key to the first clockwise node, wrapping around at the end.

Suppose A=10, B=50, C=90. Key 30 belongs to B, key 70 to C, and key 95 wraps to A. Adding D=35 transfers (10,35] from B to D without changing other intervals. These small integer positions illustrate the rule.

Before: 10(A) ---- 30(key) -------- 50(B) -------- 90(C)
After:  10(A) ---- 30(key) -- 35(D) -- 50(B) ----- 90(C)

With ideal uniform distribution and equal weights, adding a node takes roughly 1/(N+1) of keys on average. This is not an exact guarantee for each expansion, byte volume, or request load.

Virtual nodes

One position per machine can leave a successor overloaded after a failure. Virtual nodes assign several distributed positions to each physical machine, spreading transferred intervals. More positions can represent greater capacity.

Costs include routing metadata and migration management. Virtual nodes cannot split one hot key, and balanced key counts need not imply balanced memory consumption.

Membership and routing versions

Clients, proxies, or servers need a membership view and ring version. Different versions can send the same key to different owners.

Migration can involve forwarding, redirects, or controlled reads from old and new locations. Writes need explicit ownership and cutover rules. Removing a node solely on a local timeout can mistake a partition for failure and create competing writers.

Placement versus recovery

Placement determines where data belongs; replication determines where additional copies exist. Replicas should span physical machines and relevant failure domains. Several virtual nodes on one machine are not independent backups.

Failed caches can rebuild from a source of truth. Durable data needs existing replicas or another recovery source. Expansion still needs historical copying, change catch-up, and validation.

Hotspots and alternative placement

Hot keys may need local caches, replicated reads, splitting, or rate limiting, each with separate consistency and invalidation decisions. Alternatives such as rendezvous hashing also reduce remapping.

Redis Cluster illustrates why product details matter: it maps 16,384 fixed hash slots onto nodes and migrates slots, rather than directly using this virtual-node ring. The Redis Cluster specification documents slots and redirects.

Related notes and source

Sharding · Caching · CAP

Learning reference: Hello Interview · Consistent Hashing, reviewed through the authenticated written chapter. The integer-ring example and routing-version discussion are independent explanations.

CAP and Consistency Trade-offs

CAP explains incompatible guarantees for distributed data during a network partition. Use it to specify failure behavior for particular reads and writes rather than labeling an entire product CP or AP.

Define the terms

CAP consistency commonly means linearizability: operations appear to take effect between invocation and response while respecting real-time order. A read starting after a successful write cannot return a value superseded by it.

Availability requires requests received by non-failing nodes to eventually obtain corresponding operation results. Indefinite waiting or universal errors do not satisfy it. It is not monthly uptime and does not itself specify a fixed response-time bound.

A partition prevents reliable communication between groups of nodes. Real systems cannot simply choose never to experience one. Without a partition, CAP does not require sacrificing either consistency or availability.

A two-region example

Suppose US and European replicas each show one remaining GPU allocation. During a partition, each receives a request. If both promise success, they can overcommit. If an isolated region waits or rejects because it cannot confirm ownership, those operations lose availability.

Consistency-first does not necessarily stop every service. A majority protocol may continue writes on one side while an isolated minority stops committing. The result depends on the protocol, assumptions, and read path. Drawing a leader alone does not prove strong consistency.

Choose by operation

Specify affected records, operations, and invariants. A broad statement such as “the whole system is strongly consistent because it handles money” is insufficient.

Distinguish consistency models

Linearizability concerns real-time order within its specified scope. Serializability makes transaction effects equivalent to some serial execution. Neither automatically implies the other. Strict serializability additionally respects real time.

Read-your-writes and monotonic reads provide session guarantees rather than global linearizability. Eventual consistency converges after writes stop under required communication and repair assumptions; it does not inherently bound convergence time or choose conflict resolution.

ACID consistency concerns valid states and constraints, not CAP’s C. SQL, NoSQL, transactions, and replication are not standalone proofs of cross-region guarantees.

Replication, quorums, and read paths

Synchronous replication coordinates before acknowledgment. Asynchronous replication can return earlier while replicas lag. Leader reads, committed versions, and failover durability affect what clients observe.

R + W > N makes read and write sets overlap, but overlap alone does not prove linearizability. Concurrent writes, version rules, failed operations, membership changes, and recovery still need a correct protocol.

Access paths can differ. DynamoDB’s consistency documentation distinguishes tables and local versus global secondary indexes. A strong option on the base table does not establish identical guarantees elsewhere.

Latency without partitions

PACELC highlights availability versus consistency under partitions and coordination latency versus consistency in normal operation. Cross-continent confirmation introduces network waiting, but implementation details still determine guarantees.

The full client path matters: a strongly consistent database hidden behind an old cache can still expose stale API results. Consider caching, sessions, replication, and failover together.

Related notes and source

Caching · Data modeling · Sharding

Learning reference: Hello Interview · CAP Theorem, reviewed through the authenticated written chapter. Quota allocation and read-path reasoning provide an independent explanation.

Capacity Estimation and Orders of Magnitude

Estimates should support decisions: whether one machine suffices, whether caching helps, how long data can be retained, and whether failure leaves enough capacity. Use assumptions and measurements rather than universal vendor benchmark limits.

Convert demand into work

Daily active users are neither simultaneous users nor requests per second. Estimate operations per user and the service calls, database accesses, and messages each operation creates.

Average requests/s = daily operations / 86,400
Peak requests/s = average requests/s × an explicit peak factor
Backend reads/s ≈ requests/s × reads/request × miss rate

Peak factors depend on time zones, scheduled work, events, and tenant skew. Fan-out, retries, and background work increase internal traffic beyond external demand.

A complete log-ingestion example

Assume 10 million daily records, 2 KB each in decimal units, and a 10× peak. These are illustrative assumptions, not measurements.

Indexes, metadata, headers, replication traffic, backups, and compression remain separate. Three replicas are not three independent historical backups: deletion can propagate to all copies.

Latency, throughput, and concurrency

Latency measures request duration; throughput measures completed work per time; concurrency measures simultaneous work. They are not interchangeable.

In a stable system, Little’s Law uses averages: average in-flight work equals average arrival rate times average time in the system. At 2,000 requests/s and 0.1 s average duration, expect about 200 in-flight requests. Do not substitute p99 or treat an indefinitely growing queue as steady state.

End-to-end p99 is not simply the sum of component p99 values. Fan-out, correlated failures, and queuing affect tails. Allocate budgets and verify the complete path.

Calculate resource dimensions separately

CPU depends on computation and parallel efficiency. Memory includes resident data, connection buffers, and object overhead. Storage needs capacity, IOPS, bandwidth, and durability analysis. Network traffic includes responses, replication, and cross-region exchange.

At an assumed 32 KiB per active connection, 100,000 connections use about 3.05 GiB for that component alone. This is not a fixed server overhead; TLS, application, and kernel state may add costs. Bandwidth capacity also does not determine small-request throughput when CPU or packet processing dominates.

Avoid fixed QPS limits

Point reads, joins, large transactions, durable writes, and large responses impose different costs on identical hardware. Indexes, cache state, connections, batching, and contention change results.

Report dataset size, distribution, read/write mix, payload, durability, cache state, latency targets, and errors. Sustainable capacity means throughput meeting those targets, not the highest brief rate before collapse.

Failure and recovery headroom

A cluster sufficient in normal operation may fail after losing a node or zone. Calculate remaining capacity and reserve room for replication, warmup, backlog recovery, and deployments.

Queues postpone work rather than creating capacity. At 1,500 arrivals/s and 1,200 completions/s, backlog grows by 300/s. Recovery needs processing above new arrivals. Under stable assumptions, drain time is approximately backlog / (processing rate - arrival rate).

Turn estimates into decisions

Find the tightest resource and compare targeted changes: fewer queries, better indexes, batching, or larger machines. Introduce caching, asynchronous work, or sharding when measurements and growth justify them.

Compare scenarios such as doubled record size or a peak factor rising from 10 to 20. Identify which uncertainty changes the design. Real cloud cost comparisons require current region- and configuration-specific prices.

Related notes and source

Indexes · Caching · Sharding · RL systems

Learning reference: Hello Interview · Numbers to Know, reviewed through the authenticated written chapter. All workload, connection, and backlog calculations are independent examples with explicit assumptions, not vendor promises.

Core Concepts: Complete Topic Index

Nine explanatory chapters are available as continuous reading. All prose is visible without expansion controls, quizzes, or self-checks. Each chapter connects concepts, mechanisms, suitable uses, and trade-offs through concrete examples.

Reading order

Networking and APIs → modeling and indexes → caching → sharding and consistent hashing → CAP → estimation. Start with one request, then consider scaling and failure. Individual chapters can also be opened directly.

Diagrams and offline reading

Each chapter includes an SVG preview. Download the interactive system-design overview, Chinese as standalone HTML. The complete pack contains both languages, diagrams, and an Obsidian-ready folder.

Reading references

All nine written topics were reviewed through the existing authenticated Hello Interview session. These guides are independently organized around system questions with primary documentation and worked examples; they do not transcribe course videos or quizzes. Other patterns, technologies, and design problems are outside this set.

Hello Interview curriculum · Back to system design

AI-assisted Software Engineering

Deliver verifiable software with AI through context preparation, debugging, review, and acceptance checks.

Study routine

Explain one question without notes before revising it. Record evidence, unverified assumptions, and a next review date.

Progress: review needed → explain → solve independently → handle follow-ups.

Notes

• Practical Delivery & Acceptance Checklist

Practical Delivery & Acceptance Checklist

A complete practice loop

Clarify requirements → build a minimal solution → verify with tools → review manually → reflect. Define acceptance criteria before asking AI to break down the task.

• Context: inputs, outputs, existing interfaces, environment, and fixed constraints.
• Tools: file search, tests, logs, and diffs.
• Debugging: reproduce, narrow the scope, hypothesize, verify, and fix.
• Review: correctness, failure paths, dependencies, credential handling, and maintainability.
• Evidence: observed results, uncovered boundaries, and next steps.

Practice log

API design · Project deep dive · Module index

Reinforcement Learning & Training Systems

Connect learning objectives, data flow, and training infrastructure to reason about throughput, stability, and evaluation.

Study routine

Explain one question without notes before revising it. Record evidence, unverified assumptions, and a next review date.

Progress: review needed → explain → solve independently → handle follow-ups.

Notes

• RL Systems Knowledge Map

RL Systems Knowledge Map

This is a framework to fill in, not a claim about completed projects or proficiency.

Answer template

Definition → mathematical objective or data flow → system constraints → failure modes → measurable evidence.

Capacity estimates · Data modeling · Project deep dives · Module index

Company & Role Research

Turn public evidence into role alignment, technical judgment, and useful interview questions.

Study routine

Explain one question without notes before revising it. Record evidence, unverified assumptions, and a next review date.

Progress: review needed → explain → solve independently → handle follow-ups.

Notes

• Company & Role Research Template

Company & Role Research Template

Basics

Company, role, level, team, and interview date: to be filled in.

Evidence table

Prefer job descriptions, engineering blogs, papers, public code, and official product material. Recheck fast-changing information before the interview.

Develop a point of view

• What problem does the team solve, and what is its success metric?
• Which of my projects addresses a related challenge, with supporting evidence?
• Prepare three evidence-based questions without guessing private architecture.

Project deep-dive template · Module index

Project Deep Dives

Explain personal contributions, key decisions, outcomes, and lessons with real evidence.

Study routine

Explain one question without notes before revising it. Record evidence, unverified assumptions, and a next review date.

Progress: review needed → explain → solve independently → handle follow-ups.

Notes

• Project Deep-dive Template

Project Deep-dive Template

Do not invent experience, metrics, or contributions. Fill this template with actual materials.

90-second introduction

Problem and context → my responsibility → key technical decision → verifiable outcome → most important lesson.

Technical evidence

Rehearse follow-ups

Why this approach? What was technically hardest? What would change if you rebuilt it? How do you attribute the result to your work?

System design · RL systems · Company research · Module index