Posts

Overview Failover and fallback both describe what a system does when something breaks, but they differ in what changes. Failover swaps a failed component for an identical redundant one so behavior stays the same, while fallback switches to a different, usually simpler or lower-fidelity path when the preferred one is unavailable. Confusing the two leads to designs that promise seamless continuity but actually degrade functionality, or vice versa. Comparison Diagram FailoverFallbackClientPrimary (Active)same behaviorStandby (identical)takes over, same outputredundant component, unchanged functionClientPrimary Pathfull behaviorFallback (degraded/default)reduced or cached responsealternate path, changed function Comparison Table Aspect Failover Fallback Core action Switch to a redundant, identical component Switch to a different, usually simpler alternative Functional parity Preserves full functionality and quality Often reduced functionality, accuracy, or freshness Typical scope Infrastructure/system level (servers, nodes, DCs) Application/logic level (methods, values, services) Trigger Health check or heartbeat failure detection Exception, timeout, cache miss, or unmet condition Example Active database node dies; standby replica takes over queries transparently Live pricing API call fails; app falls back to last cached price Recovery expectation Usually paired with failback once primary recovers Often stays on fallback until explicitly retried or root cause fixed User-visible impact Ideally none, if failover is seamless Often visible as a lower-quality or generic result Design goal High availability / continuity of service Graceful degradation / resilience of a single call or feature Key Differences Failover replaces a broken component with an equivalent one; fallback replaces a preferred behavior with a lesser one. Failover targets infrastructure-level continuity (nodes, clusters, regions); fallback targets code-level resilience (a single function or request). Failover implies redundancy of identical capability; fallback implies acceptance of reduced capability. Failover is often followed by ‘failback’ to the restored primary; fallback usually persists until the underlying issue is resolved or retried. A system can use both together: infrastructure fails over to a standby, while an individual call within that system falls back to cached data. When to Use Each Failover ...

Overview Both practices extend continuous integration by automatically building, testing, and preparing every code change for release. The distinction is the final step: Continuous Delivery leaves the production release as a manual, human-triggered decision, while Continuous Deployment releases every change that passes the pipeline straight to production with no human gate. Comparison Diagram Continuous DeliveryCommitBuild &TestStagingManualGateProductionHuman approves releaseContinuous DeploymentCommitBuild &TestStagingAutoDeployProductionPipeline releases automaticallyBoth automate build, test, and staging - only the final release step differs Comparison Table Aspect Continuous Delivery Continuous Deployment Core definition Every change is automatically built, tested, and made release-ready Every change that passes the pipeline is automatically released to production Production release trigger Manual approval (button click, ticket, scheduled window) Fully automated, no human step Human involvement Required at the final gate None after code review/merge Release frequency As often as the business decides to approve As often as commits pass the pipeline, often multiple times a day Pipeline requirement Automated build, test, and staging deployment Same, plus very high test coverage and confidence since there’s no manual check Rollback strategy Can hold a release before it ships if issues are found Must rely on fast automated rollback/feature flags since bad code ships immediately Risk profile Lower immediate risk; human judgment as a final safeguard Higher immediate risk; depends entirely on pipeline quality Typical adopters Regulated industries, teams needing release scheduling or compliance sign-off Mature engineering orgs with strong test automation, e.g. SaaS with frequent small releases Key Differences Continuous Delivery guarantees releasability, not release — a human still decides when code ships Continuous Deployment removes the human gate entirely, so passing the pipeline is equivalent to shipping Continuous Deployment demands much stronger automated test coverage, since there’s no manual safety check before production Continuous Delivery supports scheduled or compliance-driven release windows; Continuous Deployment does not Both require the same underlying CI foundation — automated build, test, and staging deployment When to Use Each Continuous Delivery ...

Overview SQL (relational) databases organize data into fixed-schema tables linked by foreign keys and queried with a standardized language, prioritizing consistency and structured relationships. NoSQL (non-relational) databases store data as documents, key-value pairs, wide columns, or graphs with flexible or absent schemas, prioritizing horizontal scale and adaptability. The right choice depends on how relational your data is and whether you need strict consistency or elastic scale. Comparison Diagram SQL (Relational)NoSQL (Non-Relational)usersidname1Alice2Bobordersiduser_iditem1011Book1021PenData split across tables,joined via foreign keysuser document{"id": 1,"name": "Alice","orders": [{ "id": 101,"item": "Book" },{ "id": 102,"item": "Pen" }]}Related data embeddedin one flexible document Comparison Table Aspect SQL (Relational) NoSQL (Non-Relational) Data model Tables with fixed rows/columns, normalized via foreign keys Documents, key-value pairs, wide-column, or graph structures with per-record flexibility Schema Schema-on-write, enforced by the engine (types, constraints, CREATE TABLE) Schema-on-read; little to no enforcement, validation left to the application Query language Standardized SQL (SELECT, JOIN, WHERE) Varies by product — Mongo query API, CQL, Gremlin, or simple key lookups Consistency model Strong ACID transactions across tables by default Often eventual/tunable consistency (BASE); some now offer document-level ACID Scaling approach Vertical scaling first; horizontal sharding possible but complex Built for horizontal scaling/sharding across commodity nodes Relationships Modeled via joins and foreign keys Modeled via embedding (denormalization) or manual reference resolution Typical examples PostgreSQL, MySQL, SQL Server, Oracle MongoDB, Cassandra, DynamoDB, Redis, Neo4j Best fit workload Complex multi-entity queries, reporting, transactional integrity High-volume writes, evolving schemas, massive horizontal scale Key Differences SQL normalizes data into related tables with a fixed schema enforced at write time; NoSQL stores flexible, often denormalized records with schema left to the application. SQL guarantees ACID transactions across tables by default; most NoSQL stores trade strict consistency for availability/partition tolerance (BASE). SQL relationships require JOINs across tables; NoSQL typically embeds related data in one document to avoid joins, or resolves references manually. SQL databases scale vertically first and shard with effort; NoSQL databases are architected from the start for horizontal, distributed scaling. Changing a SQL schema requires a migration; NoSQL documents can differ in shape from record to record with no migration needed. When to Use Each SQL (Relational) ...

Overview A process is an independently executing program instance with its own private address space, while a thread is a lightweight unit of execution that runs inside a process and shares that process’s memory with its sibling threads. The distinction matters because it determines how much isolation, communication overhead, and crash-safety you get versus how cheap context switching and data sharing are. Comparison Diagram Process Thread Process A Code Data Heap Stack Process B Code Data Heap Stack no shared memory (IPC only) single process address space Shared Code / Data / Heap Thread 1 Stack Registers Thread 2 Stack Registers Thread 3 Stack Registers shared heap/code, private stack per thread Comparison Table Aspect Process Thread Memory space Own isolated virtual address space Shares address space with sibling threads in the same process Creation cost Expensive (fork/CreateProcess, new page tables) Cheap (allocate stack + TCB, reuse existing address space) Context switch cost Higher (flush TLB, swap page tables) Lower (same address space, just swap registers/stack pointer) Communication Requires IPC: pipes, sockets, shared memory, message queues Direct via shared variables/heap; needs locks/mutexes for safety Fault isolation A crash typically stays contained to that process A crash (e.g. bad pointer, unhandled exception) can take down the whole process Scheduling unit OS schedules processes (which contain ≥ 1 thread) OS (or runtime) schedules threads independently within a process Concurrency primitives needed Rarely needed within a single process Mutexes, semaphores, atomics to guard shared state Typical use case Running separate, independently-failing programs (browser tabs as processes, microservices) Parallelizing work within one program (web server handling many requests, UI thread + workers) Key Differences A thread lives inside a process and shares its code, heap, and open file handles; a process owns its own private address space. Threads communicate by directly reading/writing shared memory (needing synchronization); processes must use explicit IPC mechanisms. Creating and context-switching a thread is much cheaper than doing the same for a process, since no new address space or page table is involved. A crashing thread can corrupt or kill its entire parent process; a crashing process is generally isolated from other processes by the OS. Multiple threads share one process’s resource limits (file descriptors, memory quota); each process gets its own. When to Use Each Process ...

Overview Authentication (AuthN) confirms who a user or system claims to be, typically through credentials like passwords, biometrics, or tokens. Authorization (AuthZ) determines what an already-authenticated identity is permitted to do or access. The two are sequential and often conflated, but security bugs frequently trace back to confusing one for the other — e.g., checking that a user is logged in without checking they’re allowed to see a specific resource. ...

Overview REST and GraphQL are both HTTP-based API paradigms that differ fundamentally in how clients request data. REST exposes multiple URLs with server-defined response shapes; GraphQL exposes a single endpoint where the client’s query body dictates exactly which fields and relationships to return. The distinction drives decisions around over-fetching, N+1 latency, HTTP cacheability, and schema contracts. Comparison Diagram RESTmultiple endpoints, fixed shapeClientGET /usersGET /postsGET /comments3 requestsEach response = full object:{ id, name, email, avatarUrl, createdAt, role, prefs }only name+email needed → over-fetchRelated data → N+1 round-tripsBreaking change → new URL, e.g. /v2/GET · cacheable · status codesGraphQLone endpoint, client-declared shapeClientPOST /graphql1 requestquery (client-authored)query { user(id: 1) { name email } posts { title }}SDL schema (server)type User { name: String! email: String posts: [Post]}Response: exactly what was declared{ user: { name, email }, posts: [{ title }] }Schema evolves via @deprecated, no versioningPOST · typed schema · introspectable Comparison Table Aspect REST GraphQL Endpoints One URL per resource type — GET /users, POST /orders, etc. Single URL (POST /graphql); resource selection is in the query body Response shape Fixed by the server; client receives all fields the endpoint defines Declared by the client per query; only the requested fields are returned Over/under-fetching Chronic: server returns full objects; client discards unused fields or must make extra requests for missing ones Eliminated by design: resolvers return only fields the query specifies HTTP caching Native: GET responses cache at CDN and browser level by URL + headers Non-trivial: queries are POST bodies; requires persisted queries or APQ for cache-key stability Type system Optional — enforced only if you add OpenAPI/JSON Schema; not validated at runtime by default Mandatory SDL schema; all queries are parsed and validated against it before execution Versioning Breaking changes typically require new URL paths (/v1/, /v2/) or custom Accept headers Additive schema evolution with @deprecated directives; a single endpoint surface stays stable Error handling HTTP status codes carry semantic meaning: 200, 404, 422, 500, etc. Always 200 OK; errors surface in an errors[] array alongside any partial data Introspection / discoverability Requires an external spec (OpenAPI/Swagger); not built into the protocol Built-in: query __schema or __type to get the full type graph at runtime Key Differences REST has one endpoint per resource; GraphQL has one endpoint for the entire API, and the query body — not the URL — determines what data comes back. REST responses return all server-defined fields for a resource (over-fetch), and fetching related data requires additional round-trips (N+1 problem). A single GraphQL query can traverse multiple types and return exactly the fields requested. REST uses standard HTTP verbs and status codes, making GET-based CDN and browser caching trivially available. GraphQL queries travel as POST bodies, breaking HTTP cache semantics by default and requiring explicit workarounds. GraphQL’s SDL provides a mandatory, introspectable type contract enforced at parse time. REST type contracts are optional add-ons (OpenAPI); the server can return anything without violating the protocol. REST breaking changes typically force a new URL version (/v2/); GraphQL prefers additive schema evolution with @deprecated, keeping a single endpoint surface over the API’s lifetime. When to Use Each REST ...

Overview The stack and heap are two distinct memory regions used for different allocation strategies at runtime. The stack manages function call frames automatically via a single pointer increment/decrement, while the heap handles dynamic allocations with flexible lifetimes through an allocator. The distinction directly affects allocation speed, data lifetime, size constraints, and thread safety — core considerations in systems, embedded, and performance-sensitive programming. Comparison Diagram STACKgrows downward, LIFOhighlowframe: main()frame: compute(n)frame: factorial(3)SPunusedauto-managed · O(1) · fast~1-8 MB per threadHEAPunordered, explicit lifetimeObjectVec<T>freeHashMapBoxfreeString dataArcmanual/GC · flexible · fragmentslimited by OS / RAM Comparison Table Aspect Stack Heap Allocation mechanism Pointer decrement — O(1), no bookkeeping Allocator call (malloc/new) — higher constant, free-list bookkeeping Deallocation Automatic on scope/frame exit Explicit (free/delete) or garbage collector Data lifetime Bound to the declaring scope or call frame Arbitrary; can outlive any function call Size constraint Fixed at thread creation (typically 1–8 MB) Limited only by available virtual memory / RAM Size known at compile time Required — compiler must know the type’s layout Not required — length/capacity decided at runtime Fragmentation None — LIFO order keeps allocation contiguous Yes — internal and external fragmentation accumulate over time Thread ownership Each thread has its own stack; no synchronization needed Shared across threads; allocator must serialize internally Failure mode Stack overflow → immediate crash (SIGSEGV/signal) OOM → null / exception / OOM-killer; potentially recoverable Key Differences Stack allocation is a single SP register decrement; heap allocation invokes an allocator with metadata updates, free-list traversal, and possible OS syscalls. Stack lifetime is strictly scoped to the function frame — data cannot be returned by pointer from the stack safely; heap memory can be returned, stored globally, or transferred across threads. Each thread has its own stack and needs no locking; the heap is process-wide and requires allocator-level synchronization on every alloc/free. Stack size is fixed and small (set by the OS or linker script); heap can grow dynamically, making it the only viable region for large buffers or runtime-sized collections. Heap fragmentation is a real operational concern in long-lived or allocation-heavy processes; the stack never fragments because it always grows and shrinks from one end in LIFO order. When to Use Each Stack ...

Overview Latency and bandwidth both describe network performance, but they measure completely different things: latency is how long a single piece of data takes to travel from source to destination, while bandwidth is how much data can move through the connection per second. A link can have huge bandwidth and still feel laggy, or tiny bandwidth and still respond instantly — understanding which one is limiting you determines whether the fix is a faster link or a shorter path. ...

Overview Circuit switching and packet switching are the two fundamental ways a network can move data between endpoints. Circuit switching reserves a dedicated path for the full duration of a session, like a traditional phone call, while packet switching breaks data into independent packets that share network links and find their own way to the destination. The choice affects everything from latency predictability to how efficiently bandwidth gets used. Comparison Diagram Circuit Switching Packet Switching A B Dedicated path reserved for the entire call A B 1 2 Packets routed independently, paths may differ, may arrive out of order Comparison Table Aspect Circuit Switching Packet Switching Connection setup Requires an explicit call-setup phase (signaling) before any data flows No setup phase; data is sent as soon as packets are ready Path allocation A fixed end-to-end path is established and used for the whole session No fixed path; each packet is routed hop-by-hop and may take a different route Resource reservation Bandwidth is exclusively reserved, so idle time on the circuit is wasted Bandwidth is statistically multiplexed and shared among many flows Data transfer format Continuous stream of data sent in the order it was generated Data split into discrete packets, each carrying its own header for routing Latency and jitter Predictable, constant latency once the circuit is established Variable latency and jitter caused by queuing and differing routes Ordering and reliability Data always arrives in the order sent, since the path never changes Packets can arrive out of order or be lost, requiring reassembly/retransmission Failure handling A link failure breaks the whole call, forcing re-establishment Traffic can be dynamically rerouted around a failed link Session teardown An explicit signal releases the reserved circuit when the call ends No teardown needed; the flow simply stops when packets stop being sent Key Differences Circuit switching reserves a dedicated path for the whole session; packet switching has no fixed path at all Circuit switching wastes idle capacity through exclusive reservation, while packet switching relies on statistical multiplexing to share bandwidth Packets can be independently rerouted around failures, while a circuit failure kills the entire call Circuit switching guarantees ordered, steady-latency delivery; packet switching risks out-of-order arrival and jitter A circuit needs an explicit call setup phase before data flows, while packet switching starts transmitting immediately When to Use Each Circuit Switching ...

Overview Full duplex and half duplex describe how a communication link handles data flowing in both directions. A full duplex link sends and receives at the same time over independent paths, while a half duplex link shares a single channel and must alternate between sending and receiving. The distinction determines whether devices collide, how much of the link’s bandwidth is usable, and how much delay is added when a device switches from listening to talking. ...