TRT
Sign in

// trace

Traces

Step-by-step walks of what actually executes: syscall → kernel → hardware → result. The atomic unit of The Runtime Theory.

  1. algorithmsTrace an Array InsertionFollow an array insertion from capacity check through resize, element shift, and write, showing why middle insertion is O(n).
  2. algorithmsTrace a Recursive FactorialFollow factorial(5) from the initial call through five stack frames, the base case at factorial(0), and the return unwinding that produces 120.
  3. networkingTrace a Packet Through Network LayersFollow a single packet from the application layer through transport, network, link, and physical layers to its destination and back.
  4. operating systemsTrace a Process LifecycleFollow a process from creation through ready, running, I/O wait, back to ready, and termination — the five states and how the kernel transitions between them.
  5. system designTrace a Cross-Region FailoverFollow traffic from a healthy primary region through failure detection, circuit breaker trip, failover decision, and traffic shift to a backup region.
  6. system designTrace a Database Write in a Leader-Follower SetupFollow a write from the application through the WAL, leader commit, follower replication, and client acknowledgment.
  7. algorithmsTrace an Array Read Against a Linked List WalkCompare reading array index 3 in one step with walking four linked nodes, and see why scans favor arrays.
  8. algorithmsTrace Counting Steps on a 4-by-4 GridCount 16 body runs in nested loops, then contrast with a halving loop to see where n-squared and n log n come from.
  9. algorithmsTrace Breadth-First Search Across Four VerticesRun BFS from vertex 0 over edges to 1, 2, and 3, watch the queue order, and record each distance.
  10. algorithmsTrace Inserting amy Where Slot 5 Is TakenHash amy to slot 5, collide with bob, probe to slot 6, and see why the table doubles before it fills.
  11. algorithmsTrace Finding 8 by Scan and by Binary SearchSearch [2, 4, 6, 8, 10] for 8 both ways: five reads by scan, two probes by binary search, and the boundary rules.
  12. algorithmsTrace Pushing 1 Onto a Heap and Finding 4 in a TreeSift 1 up the heap [3, 5, 4], then walk a search tree down to 4, and feel why each follows one path.
  13. databasesTrace: Find the Data Access That Dominates Query CostDatabase performance depends on how many rows and pages a query touches, how much data moves between operators, and whether the working set fits in memory. An index can reduce search work, but the full execution plan and actual workload determine whether that reduction matters.
  14. databasesTrace: How a B-Tree Index Narrows a Database SearchA database index is an auxiliary structure that helps find rows without scanning every table page. A B-tree keeps keys in sorted order across pages and uses separator keys to direct a search from the root toward a leaf. The index is valuable when its lookup cost is lower than the work it avoids.
  15. databasesTrace: Reading a Query Plan as an Execution HypothesisA query planner estimates alternative ways to produce a result and chooses one using statistics and cost assumptions. A plan is an executable tree of operators such as scans, joins, sorts, and aggregates. Reading it helps explain where rows are found and how intermediate results are combined.
  16. databasesTrace: Replication Improves Availability at a Consistency CostReplication stores copies of data on multiple machines to improve availability, read capacity, or recovery. The system must define how writes reach replicas and what reads are allowed to observe. “Consistent” is not one universal behavior; the contract should name ordering and freshness guarantees.
  17. databasesTrace: Transactions, Isolation, and MVCC SnapshotsA transaction groups operations under a database contract such as atomicity and consistency. Multi-version concurrency control keeps versions of rows so readers can observe a consistent snapshot while writers create new versions. The exact snapshot and conflict rules depend on the database and isolation level.
  18. networkingTrace: Designing APIs Around Explicit SemanticsAn API contract defines the meaning of operations, inputs, outputs, errors, and side effects. A good contract lets clients reason about retries and compatibility without depending on undocumented server behavior. HTTP methods communicate broad intent, while the application contract defines the resource-specific rules.
  19. networkingTrace: Treat Browser Input as Data at Every BoundaryBrowser security depends on keeping untrusted data from becoming executable code or changing the meaning of a command. Validation checks whether data fits an expected shape; context-aware output encoding ensures text is interpreted as text in HTML, an attribute, a URL, or JavaScript.
  20. networkingTrace: Caching and Routing Change the Request PathA cache stores reusable results near the request path to reduce repeated work or latency. Routing decides which server or shard handles a request. Together they affect freshness, locality, load distribution, and which layer is responsible for serving a particular version of data.
  21. networkingTrace: DNS Resolution Is a Chain of Cached QuestionsDNS maps names to typed records through a distributed hierarchy. A stub resolver usually asks a recursive resolver to find an answer. That resolver may consult caches, follow referrals from root to top-level and authoritative servers, and return records with a time-to-live.
  22. networkingTrace: Authentication, Sessions, and AuthorizationAuthentication answers who or what is making a request; authorization decides which actions that identity may perform on a resource. A session binds later requests to an authenticated context. Keeping these decisions separate makes access rules easier to audit and change.
  23. networkingTrace: Store Password Verifiers, Not Recoverable PasswordsPassword storage should make a stolen database expensive to search. A password hashing function is intentionally slow and memory-intensive compared with a general-purpose hash. Each password needs a unique random salt so equal passwords do not produce equal stored verifiers.
  24. networkingTrace: TCP Provides an Ordered Byte StreamTCP provides applications with a reliable, ordered byte stream over an IP network. It tracks sequence numbers, acknowledges received ranges, retransmits data when needed, and applies flow and congestion control. The application sees a stream of bytes rather than message boundaries.
  25. networkingTrace: Threat Modeling Starts With Assets and BoundariesThreat modeling is a structured way to ask how a system could be misused or attacked. Begin with assets worth protecting, actors, data flows, and trust boundaries. A boundary marks where assumptions change, such as browser to server, service to database, or tenant to tenant.
  26. networkingTrace: TLS Establishes Keys and Authenticates a PeerTLS protects an application connection by negotiating cryptographic parameters, establishing shared traffic keys, and authenticating a server certificate under a trust policy. Modern TLS separates the handshake that sets up security from the encrypted application records that carry HTTP or another protocol.
  27. operating systemsTrace Linux read() From Userspace to the KernelFollow a Linux read request through the C library boundary, file descriptor lookup, page cache, and returned byte count.
  28. operating systemsTrace: Branch Prediction and Exposing Parallel WorkBranches make program control depend on data. A modern CPU predicts likely directions so it can keep fetching instructions before the condition is fully resolved. Correct predictions preserve pipeline flow; incorrect ones require discarding speculative work and refilling parts of the pipeline.
  29. operating systemsTrace: A Bytecode VM Executes a Portable Instruction SetBytecode is a compact instruction representation designed for a virtual machine rather than one physical processor. A VM fetches instructions, decodes operands, and updates execution state such as a stack, registers, frames, and heap. This layer can provide portability and runtime checks.
  30. operating systemsTrace: Why Memory Locality MattersProcessors use a hierarchy of storage because small, nearby storage can be accessed faster than large, distant storage. A cache keeps copies of recently or predictably used memory blocks. Programs benefit when accesses show temporal locality, reusing data, or spatial locality, touching nearby addresses.
  31. operating systemsTrace: From Source Files to a Running ProgramA build turns source text and dependencies into an executable representation through distinct stages. A compiler typically parses and checks source, translates it to an intermediate or machine representation, and emits object files.
  32. operating systemsTrace: Synchronization Makes Shared State PredictableConcurrency means operations overlap in time; it does not require multiple CPU cores.
  33. operating systemsTrace: How Bits Become ValuesMemory stores bit patterns; a type and an operation determine how a program interprets those bits. The same sequence can represent an integer, a floating-point value, an instruction, or encoded text.
  34. operating systemsTrace: Async Code Still Runs on an Event LoopAn event loop repeatedly selects ready work and runs callbacks or tasks. Asynchronous I/O lets a program arrange for completion to be reported later so the thread can do other work meanwhile. The syntax may look sequential, but the runtime schedules continuations according to its queues and rules.
  35. operating systemsTrace: What a Function Call Places in a Stack FrameA function call transfers control while preserving enough state for the caller to resume. A calling convention defines how arguments, return values, registers, and stack alignment are handled.
  36. operating systemsTrace: Heap Allocation and Garbage CollectionThe heap holds objects whose lifetimes are not tied to one simple lexical scope. A runtime allocator reserves space, initializes an object, and returns a reference. Garbage collection reclaims memory that is no longer reachable under the collector’s object graph and root rules.
  37. operating systemsTrace: Instruction Pipelines and Dependency HazardsA processor pipeline overlaps stages of multiple instructions, much like an assembly line. Pipelining aims to increase instruction throughput; it does not necessarily reduce the latency of one instruction. The benefit depends on keeping stages supplied with independent work and resolving control decisions quickly.
  38. operating systemsTrace: When a Runtime Compiles Hot CodeA just-in-time compiler translates code while a program runs. A runtime may begin by interpreting or compiling quickly, then use execution counters or profiling to identify frequently executed paths worth optimizing. The result can be specialized using assumptions about observed types and control flow.
  39. operating systemsTrace: How a Parser Turns Tokens Into StructureA lexer groups characters into tokens such as identifiers, numbers, and punctuation. A parser consumes that token stream according to a grammar and builds a structured representation, often an abstract syntax tree.
  40. operating systemsTrace: A Process Is More Than a Program FileA program file is a persistent description of code and data; a process is a running instance with execution state and an address space. The operating system gives a process a virtual view of memory, while hardware and the kernel translate that view to physical resources under protection rules.
  41. operating systemsTrace: Processes, Threads, and the Cost of SharingA process is a protected resource container with an address space and operating-system-managed resources. A thread is an execution stream with its own program counter, registers, and stack. Threads in one process normally share code and heap memory, which makes communication cheap but coordination necessary.
  42. operating systemsTrace: Profile Before Rewriting the Slow PathProfiling attributes resource use to parts of a running program; benchmarking compares defined workloads under controlled conditions. A useful optimization starts with a hypothesis about the bottleneck and gathers evidence at the level where the cost occurs.
  43. operating systemsTrace: Virtual Memory and the Page-Fault PathVirtual memory lets each process use an address space that is translated through page tables and hardware translation caches. Pages provide the unit for mapping, protection, and often movement between RAM and storage.
  44. system designTrace: Choosing an Architecture Style From ConstraintsAn architecture style shapes how components communicate, deploy, and fail. A modular monolith can preserve one deployment unit while enforcing code-level boundaries. Services add independent deployment and scaling but also require network contracts, operations, and failure handling.
  45. system designTrace: Raft Uses Terms and Quorums to Choose a LeaderConsensus lets a group of processes agree on an ordered sequence of decisions despite specified failures. Raft separates leader election, log replication, and safety rules into understandable mechanisms. It assumes crash failures and a communication network that can delay, drop, or reorder messages.
  46. system designTrace: Containers Package Processes With Shared-Kernel IsolationA container is a way to package a process and its dependencies while applying isolation and resource controls. On Linux, containers commonly use namespaces to present scoped views of resources and control groups to account for or limit resource consumption. Containers generally share the host kernel.
  47. system designTrace: A Change Travels Through Delivery and FeedbackContinuous delivery makes a change releasable through repeatable build, validation, and deployment steps. Observability uses emitted signals to infer internal state from outside the system. Together they shorten feedback loops and make it possible to detect whether a release behaves as expected.
  48. system designTrace: Design Patterns as Named TradeoffsA design pattern names a recurring structure for solving a family of design problems. It is useful when it communicates roles and tradeoffs faster than a bespoke explanation. A pattern is not a rule to apply whenever its name sounds familiar.
  49. system designTrace: Reliability Comes From Explicit Failure BehaviorAn unreliable component does not make a system unreliable if the system contains and recovers from its failure. Reliability design starts by naming failure modes, their blast radius, detection signals, and the behavior users should see when a dependency is unavailable.
  50. system designTrace: Git History as a Reproducible Change RecordGit records snapshots and relationships between commits. A branch is a movable reference to a commit; creating a branch is cheap because it does not copy the repository. This model supports parallel work, review, and recovery when changes are small and their intent is clear.
  51. system designTrace: Infrastructure Changes Need Reviewable StateInfrastructure as code describes resources and their relationships in versioned files. A planning step compares the declared target with provider state and proposes changes. This makes infrastructure reviewable alongside application changes, but the plan is only as trustworthy as its inputs and state handling.
  52. system designTrace: Deployments Reconcile Desired StateKubernetes controllers continuously compare observed cluster state with a declared desired state. A Deployment describes a target number and version of replicated Pods; its controller creates or replaces ReplicaSets and Pods to move the system toward that target.
  53. system designTrace: Latency, Throughput, and Queueing Are LinkedLatency measures how long one operation takes; throughput measures how many operations complete per unit time. A system can have high throughput and poor tail latency if requests wait in queues. Concurrency increases work in flight, but beyond capacity it often increases waiting rather than useful output.
  54. system designTrace: Module Boundaries Should Follow ChangeA module groups decisions that are likely to change together and hides details other modules do not need. A useful boundary reduces the number of places that must change for one product decision. The public interface should express stable intent rather than expose internal storage or control flow.
  55. system designTrace: Distributed Calls Can Fail Halfway ThroughIn a distributed system, a caller may lose contact with a process that is still running, or receive no response after the remote side completed its work. A network partition, overloaded queue, crashed process, and slow dependency can look similar from the caller’s vantage point.
  56. system designTrace: Retries Need an Operation ContractA retry repeats work after the caller cannot determine whether an earlier attempt completed. Timeouts create this ambiguity: the server may have committed the operation while the response was lost. Safe retry design begins by defining idempotency, deadlines, and which errors may be transient.
  57. system designTrace: Choose Tests by the Failure They Can CatchTests provide evidence about behavior at different boundaries. Unit tests isolate a small decision; integration tests exercise collaboration between components; end-to-end tests validate a user-visible path. Each level trades feedback speed, realism, and setup cost differently.
  58. system designTrace: Start System Design With a Workload ModelA workload model describes request rates, payload sizes, read/write mix, burstiness, and latency goals. Capacity estimates are useful when they expose assumptions and identify dominant resource costs; a single total-user count rarely predicts the load a system must handle.
  59. operating systemsWhat happens when a closure is allocated?A step-by-step walk of closure creation: the captured environment, escape analysis's stack vs heap decision, and the indirect call at invocation.
  60. operating systemsWhat happens when you concatenate strings?A step-by-step walk of string concatenation: the immutable buffer, the memcpy, the quadratic loop trap, and the builder patterns that dodge it.
  61. operating systemsWhat happens when the stack overflows?A step-by-step walk from runaway recursion to the guard page: the mmap'd thread stack, the red zone, the page fault that becomes SIGSEGV, and the runtime's error.
  62. operating systemsWhat happens in one tick of the event loop?A step-by-step walk of a browser/Node event-loop turn: the macrotask, timer and I/O phases, the microtask drain, and the render step.
  63. operating systemsWhat happens when the JIT compiles your hot loop?A step-by-step walk from interpreter to machine code: profiling, tiered compilation, speculative optimization, and the deoptimization guards that keep it honest.
  64. operating systemsWhat happens when the garbage collector runs?A step-by-step walk of a GC cycle: allocation triggers it, the mutator pauses at a safepoint, mark traces live objects, and sweep returns memory.
  65. system designIdempotency: Retry with the Same Key, Dedupe Lookup, Replay ResponseA step-by-step walk from the retried request with the same idempotency key to the dedupe lookup that replays the stored response instead of re-executing.
  66. system designFanout: One Event, N Consumers, and the Isolation Between QueuesA step-by-step walk from the single published event through topic routing to per-consumer queues with independent offsets and failure isolation.
  67. databasesWhat happens when a database crashes and restarts?A step-by-step walk from crash detection and pg_control, through the checkpoint anchor, WAL replay, torn-page repair, and the skip of uncommitted work, to ready state.
  68. operating systemsWhat happens when you malloc(256)?A step-by-step walk from the libc fast path (tcache) through arenas, brk, and mmap, to the page fault you pay on first touch.
  69. system designWebhook Delivery: The Retry Schedule, Signatures, and the Final DLQA step-by-step walk from the subscriber's 500 to the exponential retry ladder, signature verification, and the dead-letter queue at the end.
  70. operating systemsWhat happens when you call a function?A step-by-step walk of a function call: registers, the call instruction, the stack frame, the return address, and what a single call actually costs.
  71. system designURL Shortener: The Write Path, Collision Retry, and the Cache-First ReadA step-by-step walk from the POST that generates a base62 key through the cache-first redirect path that serves millions of reads.
  72. system designQueue Burst: Producer Spike, Bounded Queue, Consumer Lag, BackpressureA step-by-step walk from a 10x producer spike through the growing queue, consumer lag, and the backpressure that brings the system back to steady state.
  73. system designRate Limiting: Token Bucket Refill and the Atomic Redis INCRA step-by-step walk from the request's token check to the atomic Redis counter that makes distributed rate limits race-free.
  74. system designCache Miss: The Full Path from Miss to DB to Populate to TTLA step-by-step walk from the cache GET that misses to the database query, the populate, and the TTL that sets the stampede window.
  75. databasesWhat happens when you insert into a B-tree index?A step-by-step walk from key and TID generation, through root descent with latch crabbing and binary search, leaf insertion, split cascade, and the growing tree.
  76. system designPartition Heal: Quorum Loss, Minority Step-Down, and RejoinA step-by-step walk from the network cut to quorum loss on one side, a new leader on the other, and the catch-up that reunites the cluster.
  77. system designCron Trigger Trace: Schedule Matching, Spawning, and Overlap ProtectionA step-by-step walk from cron daemon tick to schedule match, worker spawn, and overlap protection when a run outlives its interval.
  78. system designReplica Lag: Async Replication and the Read-Your-Writes ViolationA step-by-step walk from the primary's commit to the lagging replica's stale read — and the mechanisms that bound the damage.
  79. networkingWhat happens when you make an HTTPS request?A step-by-step walk of one GET: DNS, TCP, TLS, the kernel's send path, server processing, and the response coming back the same way.
  80. system designBatch Job Trace: Chunking, Per-Item Processing, Checkpointing, and ResumeA step-by-step walk from scheduler dispatch to chunked item processing, checkpoint writes, failure, and resumption from the last commit.
  81. system designDistributed Lock: Quorum Acquire, Lease Renewal, and the Fencing TokenA step-by-step walk from the quorum-based acquire through the lease heartbeat to the fencing token that protects writes against a stale holder.
  82. networkingWhat happens during a TLS 1.3 handshake?A step-by-step walk from ClientHello to Finished: key shares, certificate verification, and how TLS 1.3 fits the entire handshake into one RTT.
  83. system designRetry Trace: Backoff Schedules, Budgets, and Idempotency KeysA step-by-step walk from request failure to retry decision, exponential backoff with jitter, budget exhaustion, and safe retry.
  84. system designDistributed Commit: Two-Phase Prepare, Vote, and DecideA step-by-step walk from the coordinator's prepare phase to the vote collection and commit decision that makes N participants agree atomically.
  85. databasesWhat happens when you COMMIT?A step-by-step walk from BEGIN and dirty buffer-pool pages, through WAL buffer append, fsync, group commit, and the commit record, to the return to your client.
  86. networkingWhat happens when you open a TCP connection?A step-by-step walk of the three-way handshake: SYN, SYN-ACK, ACK, the kernel state machine, and the RTT math that prices every connection.
  87. system designConnection Pool Trace: Checkout, Reuse, Exhaustion, and QueueingA step-by-step walk from pool checkout to connection reuse, exhaustion, and waiting, with the math that decides who waits.
  88. system designRaft Log Replication: AppendEntries, Majority Ack, and CommitA step-by-step walk from a client write to the leader's log, through majority acknowledgement, to the commit index every node applies.
  89. system designRaft Leader Election: From Follower Timeout to the RequestVote QuorumA step-by-step walk from a follower's election timeout to the RequestVote quorum that produces exactly one leader per term.
  90. networkingWhat happens when you resolve a hostname?A step-by-step walk from getaddrinfo to /etc/hosts, the recursive resolver, and the root/TLD/authoritative server chain on UDP port 53.
  91. system designThe Life of an API Request: Hop-by-Hop From Client to Database and BackA step-by-step walk from client click to database row and back, with the latency each hop actually costs.