Search
29 results for “backend”
Search results
Backend Developer Roadmap
A structured path through the data, API, caching, security, and scaling fundamentals every backend engineer needs, each step links straight into a full Cloud Tech by Victor reference.
How does a load balancer detect and handle an unhealthy backend server?
Via health checks, periodic requests (a lightweight HTTP endpoint like /healthz, or a TCP connection check) sent to each backend on an interval. A server that fails a configurable number of consecutive checks is marked unhealthy and removed from the rotation; it is added back only after passing a configurable number of consecutive successful checks, which avoids flapping a server in and out of rotation on a single transient failure.
Redis Caching Patterns
Cache-aside, write-through, and write-behind explained, plus the TTL, stampede, and invalidation pitfalls that show up once Redis caching hits real traffic.
REST vs GraphQL
The real trade-offs between REST and GraphQL, over/under-fetching, caching, versioning, and when each one is the better default for an API.
What is cache stampede and how do you prevent it?
A cache stampede happens when a popular cache key expires and many concurrent requests all miss at once, each falling through to hit the (often slow) origin, database or upstream API, simultaneously, sometimes overwhelming it. Common mitigations: a short-lived lock so only one request repopulates the cache while others wait or serve stale data (the "thundering herd" lock pattern), staggered/jittered TTLs so keys do not all expire at the same instant, and serving stale-while-revalidate, returning the expired value immediately while refreshing it in the background.
What is the difference between cache-aside and write-through caching?
Cache-aside (lazy loading): the application checks the cache first; on a miss it reads from the database, then writes the result into the cache. Writes go to the database only, so the cache can go stale until the next miss or an explicit invalidation. Write-through: every write goes to the cache and the database together (usually the cache write happens synchronously as part of the write path), so the cache is always in sync with the database, at the cost of extra write latency on every mutation.
Why can naive cache invalidation cause a race condition?
If a write invalidates (deletes) a cache key and then updates the database, a concurrent read between those two steps can repopulate the cache with the old value right after it was deleted, leaving stale data cached until the next TTL expiry or invalidation. Ordering matters: update the database first, then invalidate the cache, and even then, a very unlucky interleaving with a concurrent cache-aside read can still occur, which is why short TTLs are used as a safety net rather than relying on invalidation alone for strict consistency.
What problem does GraphQL solve that REST does not, structurally?
Over-fetching and under-fetching. A REST endpoint returns a fixed shape, so a mobile client that only needs a user's name either gets the whole user object (over-fetching) or the API team has to add a new endpoint or query params for every new shape a client needs (under-fetching, solved by proliferating endpoints). GraphQL lets the client specify exactly which fields it wants in the query itself, so one flexible schema serves many different client needs without new endpoints.
Why is caching harder with GraphQL than REST?
REST responses map naturally to HTTP caching because a GET to a specific URL returns a predictable resource, so CDNs and browsers can cache by URL. GraphQL typically uses a single POST endpoint with a query body, which defeats standard HTTP/URL-based caching, most GraphQL setups instead rely on client-side normalized caches (like Apollo Client or Relay) keyed by object id and field, or persisted queries plus a CDN cache keyed on the query hash.
When would you choose REST over GraphQL for a new API?
When the API is simple, resource-shaped, and consumed by a small number of known clients with similar needs, REST's simplicity, mature tooling, and native HTTP caching usually win. GraphQL earns its added complexity (schema design, resolver N+1 management, more complex caching) when there are many different client shapes to serve, several frontends, mobile plus web, or third-party API consumers, where flexible field selection meaningfully reduces the number of purpose-built endpoints.
gRPC vs REST
How gRPC and REST differ in contracts, transport, streaming, and browser support, and when a binary RPC protocol beats plain HTTP and JSON.
REST vs GraphQL
How REST and GraphQL differ in fetching, caching, and versioning, and which fits a given API better.
Why is round robin sometimes a bad load-balancing algorithm choice?
Round robin assumes every server and every request is roughly equal cost, which is not always true, if backend servers have different capacities, or requests vary wildly in cost (a cheap health check vs. an expensive report generation), round robin can overload a server that happens to be mid-way through several expensive requests. Least-connections or weighted algorithms account for current load or server capacity instead of blindly cycling through the list.
What is metric cardinality, and why can it break a monitoring system?
Cardinality is the number of unique label/tag combinations a metric can have. A metric like `http_requests_total{user_id=...}` has cardinality equal to the number of distinct users, potentially millions, because most metrics backends store a separate time series per unique label combination. High-cardinality labels cause a combinatorial explosion in stored time series, which can degrade or crash a metrics backend entirely. The fix is keeping metric labels low-cardinality (route, status code, method) and pushing genuinely high-cardinality data (user IDs, request IDs) into logs or traces instead, where it belongs.
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.
Full-Stack Engineer Roadmap
A single path through the frontend, data, API, security, and operations fundamentals a full-stack engineer needs, bridging the existing Frontend and Backend Developer roadmaps into one sequence, each step links straight into a full Cloud Tech by Victor reference.
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.
When does semantic search (via embeddings) actually outperform traditional keyword search, and when might keyword search still win?
Semantic search wins when a query and the relevant document use different words for the same idea, "car won't start" matching a document about "vehicle fails to ignite", since embeddings compare meaning rather than literal tokens, which keyword search cannot do at all. Keyword search still wins, or at least remains necessary, for exact-match needs, an error code, a product SKU, a specific proper noun, where the literal string matters and a semantically "close" but textually different result is actually the wrong answer. This is why production search systems commonly combine both (hybrid search) rather than treating embeddings as a strict replacement for keyword matching.
What is the required contract between equality and hashing for an object used as a dictionary key, and why does the hash table need it specifically?
The contract is one-directional but strict: if two objects compare equal, they must produce the same hash value. A hash table uses an object's hash to pick which bucket to look in, then uses equality only to confirm the exact match within that bucket, so if two equal objects hashed differently, a lookup for one would search the wrong bucket entirely and never even reach the equality check that would have confirmed the match. The hash doesn't have to be unique across unequal objects (collisions are expected and handled), it just has to agree for anything that compares equal, that's the one property the whole lookup mechanism depends on.
What is the difference between requirements.txt and a lockfile, and why does it matter for reproducibility?
A typical `requirements.txt` often specifies loose version ranges (`requests>=2.28`), which means two installs at different times can resolve to different actual versions as new releases come out, not truly reproducible. A lockfile (like `poetry.lock` or `uv.lock`) pins the exact resolved version of every dependency and transitive dependency, so installing from it produces the identical dependency tree every time, on any machine. The distinction matters because a subtle bug caused by a transitive dependency's patch version can be nearly impossible to reproduce without a lockfile guaranteeing everyone has the exact same versions.
How to Configure Desktop Backgrounds, Power Settings, and Legal Notices Using Group Policy
In this lab, I implemented key Group Policy configurations to standardize system behavior, improve user experience, and strengthen security awareness across all domain joined devices. The configuration focuses on: Enforcing a consistent and professional desktop environment Preventing unauthorized o…
Name three CSS properties, besides z-index with positioning, that create a new stacking context, and why does that matter when debugging a layering bug?
Opacity below 1, any non-none `transform`, and `filter` or `backdrop-filter` with a value other than `none` all create a new stacking context, along with several others like `isolation: isolate` and `will-change` naming a stacking-context property. This matters when debugging because a completely unrelated-looking style change, adding a fade transition via opacity, or a hover effect via transform, can silently create a new stacking context and change how that element's children layer against the rest of the page, a z-index layering bug that has nothing to do with z-index values themselves, but with an accidental new stacking context somewhere in the ancestor chain.
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.
Building a Production-Ready AKS GitOps Platform with Terraform and ArgoCD
The DevOps Project That Finally Made Kubernetes, GitOps, and Terraform Click
Build a Secure Azure Environment in Minutes with Bicep: VMs, Networking, Private Endpoints & Blob Replication
A hands-on Infrastructure-as-Code lab deploying a production-ready Azure environment from a single Bicep template.
Why does a smaller, minimal base image reduce security risk beyond just producing a smaller download?
Every package present in a base image is a package that can have a known vulnerability, and a full general-purpose distribution image bundles far more OS packages, libraries, and tools than most applications actually need at runtime. A minimal image (Alpine, a distroless image, or a multi-stage build's final stage) simply has fewer things in it that could ever show up in a vulnerability scan, which is a structural reduction in attack surface, not a mitigation that has to be maintained the way a scanner's exception list does.
How does GitOps make rollbacks different from a traditional deployment rollback?
In a traditional deploy, rolling back means re-running a deployment process with an older artifact reference, a distinct operation from a normal deploy. In GitOps, a rollback is just a Git revert: since the desired cluster state is fully described by the repository at any commit, reverting to a previous commit and letting the reconciliation loop pick it up produces the previous cluster state through the exact same mechanism as any other change. There is no separate "rollback pipeline" to maintain or that can itself have bugs.
MongoDB can be configured to behave more like a CP system or more like an AP system. What settings make that choice, and what are they actually trading?
Write concern and read preference are the actual levers: a write concern requiring acknowledgment from a majority of replicas favors consistency, a write isn't considered successful until enough nodes agree, at the cost of availability if too many nodes are unreachable during a partition. A looser write concern, or reading from secondaries that might lag behind the primary, favors availability, operations keep succeeding even when full replica agreement isn't achievable, at the cost of potentially reading or acknowledging data that isn't fully consistent across the cluster yet. This is exactly the CP-versus-AP trade-off CAP describes, expressed as a concrete, tunable configuration rather than an abstract theorem.
What does it mean for a secret to be "dynamic" or "short-lived," and why does that reduce risk compared to a long-lived static credential?
A dynamic secret is issued on demand, scoped to a single application instance or session, and expires automatically after a defined lease, a database credential minted when a service starts and revoked automatically when it stops, rather than a password typed in once and left valid indefinitely. If a short-lived secret leaks, its usefulness to an attacker is bounded by its remaining lease time, often minutes, instead of remaining valid until someone notices and manually rotates it. This is the same underlying idea as preferring IAM roles over long-lived access keys in a cloud provider, temporary credentials shrink the blast radius of a leak by construction, not by better hiding the secret.