Search
30 results for “state”
Search results
An application uses PREPARE to create a reusable prepared statement, then relies on it across multiple requests. What happens if it's deployed behind a transaction-pooled PgBouncer, and why?
It breaks. A SQL PREPARE statement is a session-level feature, it lives on whatever specific server connection issued the PREPARE, but transaction pooling reassigns the underlying server connection to a different client (or the same client's next transaction) as soon as each transaction ends, so there's no guarantee a later request lands on that same server connection where the prepared statement actually exists. This is explicitly documented as one of the session-based features transaction pooling breaks, along with SET/RESET, LISTEN, WITH HOLD cursors, and session-level advisory locks, all of which depend on state tied to one specific, persistent server connection. This is distinct from protocol-level named prepared statements issued via the extended query protocol (what most driver-level "prepared statements" actually are), which PgBouncer can support under transaction pooling when `max_prepared_statements` is set to a non-zero value.
Why are idempotency keys typically associated with state-changing requests like POST, and are they ever relevant to DELETE?
GET is defined to have no side effects at all, retrying it any number of times simply returns the current state and changes nothing, so there is no duplicate-side-effect risk an idempotency key could protect against, GET genuinely doesn't need one. DELETE is idempotent in the narrow sense that deleting an already-deleted resource is a no-op or a consistent "not found," but whether an idempotency key is relevant to it is API- and version-specific, not settled by the HTTP verb alone: a DELETE can still trigger complex, non-idempotent side effects (a refund, a cascading cleanup, a billing adjustment), and some APIs explicitly accept an idempotency key on DELETE for exactly that reason. Idempotency keys exist to make an operation's retry semantics explicit and safe regardless of whether the underlying operation is inherently idempotent, checking the specific endpoint's documented contract matters more than assuming based on the verb.
A socket shows up in the LISTEN state versus ESTABLISHED. What is actually different about what that socket is doing?
LISTEN means a server-side socket is bound to a port and passively waiting to accept incoming connection requests, it isn't attached to any specific remote peer yet. ESTABLISHED means a full connection has completed its handshake and is actively associated with a specific remote address and port, data can flow in both directions. Seeing a service you expect to be running not show a LISTEN socket on its expected port is usually the very first, most direct signal that the service isn't actually up or isn't bound where you think it is.
Why does wrapping several statements in `BEGIN`/`COMMIT` matter, even for a multi-step operation that's logically one action?
Without an explicit transaction, PostgreSQL commits each statement independently the moment it succeeds; if a multi-step operation (debit one account, credit another) fails halfway through, the database is left in an inconsistent, partially-applied state with no way to undo the completed step. Wrapping the statements in `BEGIN`/`COMMIT` groups them so they can be committed or rolled back together, but that alone isn't automatic protection against every failure mode: PostgreSQL only aborts a transaction on its own when a statement raises an actual SQL error, an `UPDATE` that runs successfully but matches zero rows (a mistyped account id, for instance) is not an error at all, and would otherwise be committed as if the transfer had actually happened. Making the transaction genuinely safe means checking that each `UPDATE` affected exactly the one row expected and issuing an explicit `ROLLBACK` if either check fails, only issuing `COMMIT` once both checks pass.
A component's state is preserved when a prop changes, but reset when a completely different element renders in the same spot. What determines which happens?
React associates state with a component's position in the render tree, not with the component instance or its props specifically. If the same component type renders at the same tree position across a re-render, its state is preserved regardless of what props changed. If a different component type (or a different element entirely) renders at that same position, React treats it as a genuinely different thing, destroys the old state, and starts fresh. This is why toggling a prop on the same `<Counter />` keeps its count, but swapping `<Counter />` for a `<p>` at that same spot in the tree resets it entirely, even though from the JSX it might look like a small, local change.
Why does using an array index as a list item's key cause state to attach to the wrong item once the list is reordered, and what's the fix?
With `key={i}`, React tracks each item's state by its position in the array, not by which real-world item it represents, so after reversing a list, the state that was originally at index 0 (say, an "expanded" toggle on the first item) stays at index 0 and now renders alongside whatever item ended up there after the reorder, not the original item it belonged to. The fix is using a stable, unique identifier from the actual data, `key={contact.id}`, so React can match each item to its correct state across renders regardless of how the list is reordered, added to, or filtered, rather than relying on a position that can shift under the data.
What is Terraform state and why is it required?
State is a JSON file (by default `terraform.tfstate`) that maps every resource block in your configuration to the real-world object Terraform created for it (an AWS instance ID, a DNS record, etc.). Terraform is declarative, your config describes the desired end state, not the steps to get there, so on every run it needs state to compute a diff between what exists now and what the config says should exist. Without state, Terraform would have no way to know whether a resource already exists, needs updating, or was deleted outside of Terraform.
Why is storing Terraform state locally a problem for a team, and what is the standard fix?
Local state is a single file on one person's machine, a second engineer running `terraform apply` has no idea what the first one already created, so both can independently "discover" no matching state and try to recreate resources, or worse, apply conflicting changes concurrently with no locking. The standard fix is a remote backend (S3+DynamoDB, Terraform Cloud, GCS, Azure Blob) that stores state centrally and supports locking, so only one apply can run at a time and everyone reads the same source of truth.
What does "run to completion" mean for a single task or microtask, and why does it matter for reasoning about shared state?
Once a job (a task or a microtask) starts running, it executes entirely before any other job gets a chance to run, JavaScript cannot pause a running function partway through to let another callback interleave, the way a preemptively-scheduled thread in a language like C could be interrupted mid-function. This is what makes synchronous JavaScript code within a single function safe from data races on shared state without needing locks, whatever a function does to shared variables happens atomically from the perspective of any other queued job, even though the language is single-threaded and asynchronous.
React Hooks Deep Dive
How useState, useEffect, useMemo, and useCallback actually work under the hood, plus the dependency-array and stale-closure pitfalls that trip up most React code.
Why does React require hooks to be called in the same order on every render?
React does not track hook state by name; it tracks it by call order in a linked list attached to the component's fiber. On each render, React walks that list and matches the nth useState call to the nth stored slot. If a hook is called conditionally (inside an if, or after an early return), the call order can shift between renders, and React ends up reading the wrong slot for a given hook; this is exactly why hooks cannot be called inside conditionals or loops.
What is a stale closure and how does it happen with useEffect?
A stale closure happens when a function captures a variable from a render that is no longer current, because the effect or callback was not re-created when that variable changed. Classic case: an effect with an empty dependency array reads a piece of state, since the effect only runs once, the function it closes over always sees the state value from the first render, not the latest one. The fix is to include the variable in the dependency array (or use a functional state update that does not need to read the outer value at all).
When should you reach for useMemo or useCallback, and when is it wasted effort?
They are worth it when a computation is genuinely expensive, or when the memoized value/function is a dependency of another hook, or a prop to a component wrapped in React.memo, in those cases, an unnecessary new reference on every render causes real extra work downstream. For cheap computations with no memoized consumer, useMemo/useCallback add overhead (the comparison itself, plus code complexity) without a measurable benefit, profile before reaching for them by default.
AWS VPC Networking
How Amazon VPC, subnets, security groups, and network ACLs control traffic in AWS, and why security groups (stateful, instance-level) and network ACLs (stateless, subnet-level) are not interchangeable.
Database Connection Pooling
Why transaction pooling gives far better connection reuse than session pooling, and why that same efficiency silently breaks SQL PREPARE, SET, LISTEN, and session-level advisory locks, even though PgBouncer can support protocol-level named prepared statements under transaction pooling when max_prepared_statements is enabled.
GitOps Principles
Why treating Git as the single source of truth for cluster state, instead of running kubectl/terraform apply by hand, changes how deployments, rollbacks, and audits actually work.
Linux Networking
How ip and ss replaced ifconfig and netstat as the modern tools for interfaces and sockets, what TCP socket states like LISTEN and TIME-WAIT actually mean, and how nftables organizes firewall rules into tables and chains.
Rate Limiting Algorithms
How the token bucket algorithm AWS API Gateway actually uses separates a steady-state rate from a burst allowance, and why a request only fails once the bucket is genuinely empty, not the instant the average rate is exceeded.
React Rendering & Reconciliation
Why React associates a component's state with its position in the tree, not the component instance, and why using an array index as a list key silently attaches the wrong state to the wrong item once the list reorders.
Terraform Basics
How Terraform's declarative state model, providers, and plan/apply workflow let infrastructure be versioned and reviewed like code, and the state pitfalls that trip up most teams.
When would you choose AWS Lambda over EC2 for a workload?
Lambda fits event-driven, short-lived work, an API request, a file landing in S3, a queue message, where you want to pay only for actual invocation time and never manage a server at all; a function can run for at most 15 minutes and has no state between invocations. EC2 fits workloads that need to run continuously, need OS-level control, exceed Lambda's execution-time or memory ceiling, or need to retain in-process state between requests. The decision is about execution model and constraints, not maturity, a long-running stateful service is a worse fit for Lambda regardless of how "serverless-first" a team wants to be.
How does IAM decide whether a request is allowed, and what wins if there is a conflict between an Allow and a Deny?
IAM evaluation starts from an implicit deny, nothing is allowed unless some applicable policy explicitly allows it. It then checks every applicable policy for an explicit Deny; if one exists anywhere, identity-based, resource-based, a permission boundary, an SCP, or an RCP, the request is denied regardless of how many Allow statements also apply. Beyond that, identity-based and resource-based policies are the only policy types that actually grant permissions, an Allow from either is required. Permission boundaries, SCPs, and RCPs never grant anything themselves, they only cap what a grant can reach, so the request also needs every applicable one of those to independently allow the action; any one of them failing to allow it denies the request even with a valid Allow in place. An explicit Deny always wins over an explicit Allow, no matter which policy or how specific the Allow is.
What is the difference between a security group and a network ACL in a VPC?
A security group is stateful and attaches at the instance/ENI level: it only supports allow rules, and if inbound traffic is allowed, the corresponding response traffic is automatically allowed back out regardless of outbound rules. A network ACL is stateless and attaches at the subnet level: it supports both explicit allow and explicit deny rules, numbered and evaluated in order starting from the lowest number, and because it has no memory of prior traffic, allowing inbound traffic does not automatically allow the matching outbound response, that has to be permitted by its own rule. Security groups are the primary, fine-grained access control per resource; network ACLs are a coarser, optional second layer at the subnet boundary.
How does a Network Security Group (NSG) evaluate traffic rules?
An NSG contains a prioritized list of allow/deny rules, evaluated in priority order (lowest number first) until the first rule matching the traffic's source, destination, port, and protocol is found, that rule's action wins, and no further rules are evaluated. NSGs can attach to a subnet, a network interface, or both, and are stateful, meaning an allowed inbound connection's return traffic is automatically permitted without needing a matching outbound rule. Because evaluation stops at first match, rule priority ordering is the actual logic, a broad allow rule placed before a specific deny rule silently makes that deny unreachable.
Why is "rightsizing" usually the highest-leverage cost optimization, and why do teams under-invest in it?
Rightsizing means matching provisioned capacity (instance size, allocated memory) to actual observed usage, and it typically has the biggest impact because most cloud resources are provisioned for a peak or a guess, then never revisited, meaning steady-state waste compounds every hour, every day, indefinitely. Teams under-invest in it because it requires ongoing measurement and periodic action, competing for attention against feature work that has more visible payoff, and because a resource that's "working fine" doesn't generate the same urgency as one that's broken, even if it's costing several times what it needs to.
What is the difference between a reserved/committed-use discount and a spot/preemptible instance, and when does each make sense?
A committed-use discount (reserved instances, savings plans) trades a usage commitment, a fixed amount of spend or capacity over a term, typically one or three years, for a significant price reduction on workloads you know will run continuously. Spot/preemptible instances offer a much steeper discount in exchange for the provider being able to reclaim the capacity with little notice, making them suitable only for interruption-tolerant workloads (batch jobs, stateless workers, CI runners) rather than anything requiring guaranteed uptime. Committed-use addresses predictable steady-state load; spot addresses flexible, interruption-tolerant load, using either for the wrong workload type either wastes the discount or causes outages.
What is the difference between a security group and a network ACL?
A security group is stateful and attached to individual resources (like an instance or load balancer), if you allow inbound traffic on a port, the corresponding outbound response is automatically allowed, and rules are evaluated as an allow-list only. A network ACL is stateless and attached to a subnet, evaluating both inbound and outbound rules independently for every packet, including explicit deny rules. Security groups are the primary, more commonly used tool for per-resource access control; network ACLs add a coarser, subnet-wide layer, often left at their permissive default and used mainly for defense-in-depth or to explicitly block something.
Why would you choose session pooling over transaction pooling even though it scales to fewer concurrent clients per server connection?
Session pooling is the only mode of the two that supports every PostgreSQL feature without exception, prepared statements, session variables set via SET, LISTEN/NOTIFY, session-level advisory locks, because the server connection genuinely stays with the client for as long as their session lasts. If an application depends on any of those session-level features and can't be refactored around them, session pooling is the correct choice despite its lower connection-reuse efficiency, trading raw scalability for full feature compatibility rather than working around broken session state.
What is PostgreSQL's default transaction isolation level, and what specific anomaly does it still allow that a stricter level would prevent?
PostgreSQL defaults to Read Committed, where each individual statement within a transaction sees a fresh snapshot of everything committed as of that statement's start, not the transaction's start. This prevents dirty reads (seeing another transaction's uncommitted changes) but still allows non-repeatable reads, running the same SELECT twice in one transaction can return different results if another transaction committed a change in between, because each statement gets its own snapshot rather than the transaction using one snapshot throughout. Repeatable Read fixes this specific anomaly by taking one snapshot at the start of the transaction and using it for every statement within it.
What is the difference between a Docker image and a Docker container?
An image is a read-only, layered filesystem snapshot plus metadata (entrypoint, exposed ports, environment); it never changes once built and can be shared through a registry. A container is a running (or stopped) instance of an image: Docker adds a thin writable layer on top of the image's read-only layers and starts a process inside an isolated namespace. You can start many independent containers from the same image, each with its own writable layer and state, the same way many processes can run from the same binary on a normal OS.