Exponential backoff spaces retries further apart each time (200ms, 400ms, 800ms...), but on its own it still leaves every client synchronized to the same schedule. Jitter fixes that by randomizing the delay, so retries spread out instead of arriving in lockstep.

The Retry Timeline

Each hop roughly doubles the base delay, capped at some maximum, with a random component layered on top so no two clients retry at exactly the same instant.

Fixed vs Exponential vs Jittered

A fixed delay (always wait 1s) is simple but synchronizes every client that failed at the same time. Plain exponential backoff (200ms, 400ms, 800ms, 1600ms) spreads attempts further apart over time, but clients that failed together are still retrying together at each step. Adding jitter — picking a random delay instead of the fixed exponential value — breaks that synchronization entirely.

Full Jitter

The full jitter strategy (used internally by AWS's own SDKs) computes the exponential delay as a ceiling, then picks a uniformly random value between zero and that ceiling:

delay = random_between(0, min(cap, base * 2^attempt))

This is simpler than "equal jitter" or "decorrelated jitter" variants and performs well in practice: it spreads retries across the full window instead of just adding a small amount of noise around the exponential value.

Implementation

function calculateBackoff(int $attempt, int $baseDelayMs = 200, int $maxDelayMs = 30000): int
{
    $exponential = $baseDelayMs * (2 ** $attempt);
    $capped = min($exponential, $maxDelayMs);

    return random_int(0, $capped);
}

function retryWithBackoff(callable $operation, int $maxAttempts = 5, int $baseDelayMs = 200, int $maxDelayMs = 30000)
{
    $attempt = 0;

    while (true) {
        try {
            return $operation();
        } catch (\Throwable $e) {
            $attempt++;

            if ($attempt >= $maxAttempts) {
                throw $e;
            }

            $delayMs = calculateBackoff($attempt, $baseDelayMs, $maxDelayMs);
            usleep($delayMs * 1000);
        }
    }
}

import random
import time
from typing import Callable, TypeVar

T = TypeVar("T")


def calculate_backoff(attempt: int, base_delay_ms: int = 200, max_delay_ms: int = 30000) -> int:
    exponential = base_delay_ms * (2 ** attempt)
    capped = min(exponential, max_delay_ms)

    return random.randint(0, capped)


def retry_with_backoff(
    operation: Callable[[], T],
    max_attempts: int = 5,
    base_delay_ms: int = 200,
    max_delay_ms: int = 30000,
) -> T:
    attempt = 0

    while True:
        try:
            return operation()
        except Exception:
            attempt += 1

            if attempt >= max_attempts:
                raise

            delay_ms = calculate_backoff(attempt, base_delay_ms, max_delay_ms)
            time.sleep(delay_ms / 1000)

Choosing the Parameters

baseDelayMs should roughly match how fast the downstream service actually recovers from a blip — too low and you're retrying into a still-failing service, too high and users wait needlessly on transient errors. maxDelayMs caps the worst case so a client doesn't end up waiting minutes between attempts. maxAttempts should be low enough that a genuinely broken dependency fails fast instead of hanging the caller for a long chain of doubling delays.

Common Pitfalls

Retrying without any cap on the delay means a client can end up waiting minutes for an attempt that will just fail again. Retrying without jitter defeats the entire purpose — synchronized clients stay synchronized no matter how far apart the delays get. Retrying on every kind of error, including 4xx client errors that will never succeed, wastes the retry budget on failures that a delay can't fix. And retrying indefinitely with no maxAttempts turns a transient blip into a request that never gives up and never surfaces an error to the caller.

When to Reach for This

Any call to a dependency that can fail transiently and recover on its own: HTTP calls to another service, database connections during a failover, queue consumers hitting a rate-limited API. If failures are rarely transient — a malformed request, a missing resource — backoff and retries just delay an error that was never going to succeed.

Consistent hashing fixes this by mapping both nodes and keys onto the same ring, so a topology change only remaps the keys between the changed node and its neighbor.

The Ring

Each node is hashed onto the ring (often multiple times — see "Virtual Nodes" below). To find which node owns a key, hash the key and walk clockwise until you hit the first node.

Adding or Removing a Node

When node B leaves, only the keys that were mapped to B move — to B's clockwise neighbor. Every other key stays exactly where it was. That's the whole point: roughly 1/N of the keyspace moves per topology change, not the whole keyspace.

Virtual Nodes (Replicas)

Hashing raw node names onto the ring directly creates hot spots — some nodes end up owning much bigger arcs than others. The fix: hash each node multiple times, e.g. node-A#0, node-A#1, ..., node-A#149 (150 virtual nodes is a common default). More virtual nodes means smoother distribution, at the cost of a bigger in-memory ring.

Implementation

class ConsistentHash
{
    private array $ring = [];
    private array $sortedKeys = [];
    private int $replicas;

    public function __construct(int $replicas = 150)
    {
        $this->replicas = $replicas;
    }

    public function addNode(string $node): void
    {
        for ($i = 0; $i < $this->replicas; $i++) {
            $this->ring[$this->hash("$node#$i")] = $node;
        }
        $this->sortedKeys = $this->sortedRingKeys();
    }

    public function getNode(string $key): ?string
    {
        if (empty($this->sortedKeys)) {
            return null;
        }

        $hash = $this->hash($key);
        foreach ($this->sortedKeys as $ringKey) {
            if ($ringKey >= $hash) {
                return $this->ring[$ringKey];
            }
        }

        return $this->ring[$this->sortedKeys[0]];
    }

    private function sortedRingKeys(): array
    {
        $keys = array_keys($this->ring);
        sort($keys);
        return $keys;
    }

    private function hash(string $value): int
    {
        return crc32($value);
    }
}

import bisect
import zlib


class ConsistentHash:
    def __init__(self, replicas: int = 150):
        self.replicas = replicas
        self.ring: dict[int, str] = {}
        self.sorted_keys: list[int] = []

    def add_node(self, node: str) -> None:
        for i in range(self.replicas):
            self.ring[self._hash(f"{node}#{i}")] = node
        self.sorted_keys = sorted(self.ring.keys())

    def get_node(self, key: str) -> str | None:
        if not self.sorted_keys:
            return None

        h = self._hash(key)
        index = bisect.bisect_left(self.sorted_keys, h)
        if index == len(self.sorted_keys):
            index = 0

        return self.ring[self.sorted_keys[index]]

    @staticmethod
    def _hash(value: str) -> int:
        return zlib.crc32(value.encode())

Common Pitfalls

Too few virtual nodes leads to uneven load, with hot spots on a handful of physical nodes. Using a weak or poorly-distributed hash function makes the same problem worse — prefer something like CRC32 or xxHash over a naive sum-of-bytes hash. Forgetting to remove all of a node's virtual nodes on removal leaves ghost entries that route traffic to a dead server. And rehashing the entire keyspace on every topology change defeats the whole purpose — only the ring should change, not every key's mapping.

When to Reach for This

Distributed caches doing client-side sharding, CDN edge selection, distributed hash tables, sharded databases, and load balancers that need session affinity without a central coordinator. If your cluster size is fixed and rarely changes, plain modulo hashing is simpler and perfectly fine.

The naive approach — an array you scan for the oldest entry — is O(n) per operation. The trick to O(1) is combining two structures: a hash map for O(1) lookup, and a doubly linked list for O(1) reordering.

The Structure

Every node lives in the linked list AND has a pointer stored in the hash map. head is a sentinel pointing to the most recently used node; tail is a sentinel pointing to the least recently used one, which is the eviction candidate.

The Two Operations

get(key): hash map lookup finds the node in O(1). If found, unlink it from its current position and relink it right after head (it's now the most recently used), then return its value. If not found, return null/miss.

put(key, value): if the key already exists, update its value and move it to the front, same as get. If it's new and capacity is full, remove the node just before tail (the least recently used) from both the list and the hash map, then insert the new node at the front.

Both operations only ever touch a constant number of pointers — no scanning required.

PHP Implementation

class Node
{
    public function __construct(
        public string $key,
        public mixed $value,
        public ?Node $prev = null,
        public ?Node $next = null,
    ) {}
}

class LRUCache
{
    private array $map = [];
    private Node $head;
    private Node $tail;
    private int $capacity;

    public function __construct(int $capacity)
    {
        $this->capacity = $capacity;
        $this->head = new Node('', null);
        $this->tail = new Node('', null);
        $this->head->next = $this->tail;
        $this->tail->prev = $this->head;
    }

    public function get(string $key): mixed
    {
        if (!isset($this->map[$key])) {
            return null;
        }

        $node = $this->map[$key];
        $this->detach($node);
        $this->attachToFront($node);

        return $node->value;
    }

    public function put(string $key, mixed $value): void
    {
        if (isset($this->map[$key])) {
            $node = $this->map[$key];
            $node->value = $value;
            $this->detach($node);
            $this->attachToFront($node);
            return;
        }

        if (count($this->map) >= $this->capacity) {
            $lru = $this->tail->prev;
            $this->detach($lru);
            unset($this->map[$lru->key]);
        }

        $node = new Node($key, $value);
        $this->map[$key] = $node;
        $this->attachToFront($node);
    }

    private function detach(Node $node): void
    {
        $node->prev->next = $node->next;
        $node->next->prev = $node->prev;
    }

    private function attachToFront(Node $node): void
    {
        $node->next = $this->head->next;
        $node->prev = $this->head;
        $this->head->next->prev = $node;
        $this->head->next = $node;
    }
}

The two sentinel nodes (head and tail) exist purely to avoid null checks at the boundaries — every real node always has a valid prev and next to work with.

Common Pitfalls

Forgetting to update the hash map on eviction. If you remove a node from the linked list but leave its entry in $map, the next get() for that key returns a dangling node instead of a miss.

Off-by-one on capacity checks. Check count($this->map) >= $this->capacity before inserting the new node, not after — otherwise the cache temporarily holds capacity + 1 items.

Treating get() as read-only. A cache hit still mutates state — it moves the node to the front. Skipping that step turns your LRU into a plain FIFO cache.

Using an array and array_shift() as the "queue." array_shift() is O(n) because PHP reindexes the array. This defeats the entire point of the exercise — the doubly linked list is what makes eviction O(1).

When to Reach for a Real Implementation

Don't hand-roll this for production unless you have a specific reason (embedding the cache inside a single PHP process with no external dependency, for instance). For anything shared across requests or processes, Redis's own eviction policies (allkeys-lru, volatile-lru) or a library like symfony/cache already solve this correctly and durably. The value of building it yourself is understanding why O(1) requires both structures together — neither one alone gets you there.

The Problem

Client -> POST /charge {amount: 5000} -> Server processes charge, DB write succeeds
Client -> (times out waiting for response, retries)
Client -> POST /charge {amount: 5000} -> Server processes AGAIN -> customer charged twice

The client never knows if the first request failed before or after the side effect happened. Without idempotency, a naive retry strategy silently causes double charges, duplicate emails, duplicate orders.

The Fix: Idempotency Keys

The client generates a unique key (usually a UUID) per logical operation and sends it in a header:

POST /api/v1/charges
Idempotency-Key: 7c9e6679-7425-40de-944b-e07fc1f90ae7
{ "amount": 5000, "currency": "USD" }

The server stores the key alongside the result of the first successful execution. On retry with the same key, it returns the stored result without re-executing the side effect.

Implementation with a Database-Backed Store

function handleCharge(Request $request) {
    $key = $request->header('Idempotency-Key');
    if (!$key) {
        abort(400, 'Idempotency-Key header required');
    }

    return DB::transaction(function () use ($key, $request) {
        $existing = IdempotencyKey::where('key', $key)->lockForUpdate()->first();

        if ($existing) {
            if ($existing->status === 'processing') {
                abort(409, 'Request with this key is already being processed');
            }
            return response($existing->response_body, $existing->response_status);
        }

        IdempotencyKey::create([
            'key' => $key,
            'status' => 'processing',
            'request_hash' => hash('sha256', $request->getContent()),
        ]);

        $result = processCharge($request->all());

        IdempotencyKey::where('key', $key)->update([
            'status' => 'completed',
            'response_status' => 200,
            'response_body' => json_encode($result),
        ]);

        return response()->json($result);
    });
}

The row-level lock (lockForUpdate) inside the transaction is what prevents two concurrent requests with the same key from both slipping past the "does it exist" check — this is the race condition most naive implementations miss.

Sequence of a Safe Retry

Common Pitfalls

Not hashing the request body. If a client reuses a key with a different payload (different amount, say), returning the cached response silently applies the wrong charge to the wrong intent. Store a hash of the request body with the key and reject mismatches with a 422.

No expiration. Idempotency keys should expire (24-48 hours is typical for payment APIs). Keeping them forever bloats the table and risks legitimate reuse of a UUID being blocked incorrectly, however unlikely.

Treating "processing" as "not found." If a second request arrives while the first is still mid-flight (not a retry after failure, but genuine concurrency), returning 409 (Conflict) or making the client poll is safer than letting both proceed.

Scoping keys per-endpoint, not globally. The same key sent to two different endpoints should not collide. Compose the lookup on (key, endpoint) or (key, account_id), not just key alone.

Only applying this to POST. PUT and PATCH can double-apply too if not naturally idempotent (e.g., "increment balance by 100" instead of "set balance to 100"). Prefer absolute updates over relative ones where money is involved, and use idempotency keys for both.

When You Don't Need This

Truly idempotent operations by construction (a PUT that sets absolute state, a GET, a DELETE by ID) don't need a key — retrying them is already safe. Idempotency keys matter specifically when an operation has a side effect that isn't naturally safe to repeat: charging money, sending an email, decrementing inventory, creating a resource with server-generated side effects.

Rule of thumb: any endpoint that moves money, sends a notification, or creates a resource that shouldn't be duplicated needs an idempotency key. Everything else, question whether you're overengineering.

The Classic Deadlock

Two transactions, two rows, opposite order:

-- Transaction A
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
-- ... pauses ...
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;

-- Transaction B (running concurrently)
BEGIN;
UPDATE accounts SET balance = balance - 50 WHERE id = 2;
-- ... pauses ...
UPDATE accounts SET balance = balance + 50 WHERE id = 1;
COMMIT;

If A locks row 1 and B locks row 2 at nearly the same time, A's second statement waits for B to release row 2, while B's second statement waits for A to release row 1. Neither can ever proceed.

Wait-For Graphs: How Databases Detect This

Most databases (PostgreSQL, MySQL/InnoDB, SQL Server) model lock waits as a directed graph: each transaction is a node, and an edge from T1 to T2 means "T1 is waiting on a lock held by T2." A deadlock exists exactly when this graph contains a cycle.

Periodically (or on every new lock wait, depending on the engine), the database walks this graph looking for cycles. When it finds one, it picks a victim — usually the transaction that has done the least work, or holds the fewest locks — and rolls it back, releasing its locks so the other transaction can continue.

What the Error Actually Looks Like

ERROR: deadlock detected
DETAIL: Process 1234 waits for ShareLock on transaction 5678; blocked by process 5678.
Process 5678 waits for ShareLock on transaction 1234; blocked by process 1234.
HINT: See server log for query details.

The application's job is to catch this specific error and retry the transaction — a deadlock victim is not a bug, it's the database correctly resolving an unavoidable conflict.

import time

def run_with_retry(fn, max_attempts=3):
    for attempt in range(max_attempts):
        try:
            return fn()
        except DeadlockDetected:
            if attempt == max_attempts - 1:
                raise
            time.sleep(0.05 * (2 ** attempt))  # exponential backoff

Deadlocks vs. Ordinary Lock Waits

An ordinary lock wait resolves itself once the holding transaction commits or rolls back — no cycle, no error, just a delay. A deadlock is fundamentally different: without intervention, it never resolves on its own, because every party in the cycle is waiting on another party in the same cycle. This is why detection has to be active (scanning for cycles), not passive (just waiting things out).

Prevention: Consistent Lock Ordering

The single most effective prevention technique is to always acquire locks in the same order across every transaction that touches the same set of resources. If both transactions above had updated row 1 before row 2, the second one to arrive would simply wait for the first to finish — no cycle possible.

-- Both transactions now lock in ascending id order — no deadlock possible
UPDATE accounts SET balance = balance - 100 WHERE id = LEAST(1, 2);
UPDATE accounts SET balance = balance + 100 WHERE id = GREATEST(1, 2);

In practice this often means sorting rows by primary key before issuing a batch of updates, or centralizing the lock-acquisition order in a single code path rather than leaving it to each caller.

Prevention: Keep Transactions Short

Long-running transactions hold locks longer, which widens the window during which a conflicting transaction can show up and create a cycle. Moving non-essential work (sending emails, calling external APIs, heavy computation) outside the transaction boundary shrinks that window significantly.

Prevention: Lower Isolation Where Safe

Higher isolation levels take more locks for longer. SERIALIZABLE is the most deadlock-prone; READ COMMITTED takes fewer, shorter-held locks. Not every operation needs the strongest guarantee — evaluate whether a lower isolation level is safe for a given transaction before defaulting to the strictest one everywhere.

Prevention: Smaller Lock Footprint

Locking an entire table when you only need a few rows multiplies the chance of collision. Use indexed WHERE clauses so the database can take row-level (not table-level) locks, and avoid SELECT ... FOR UPDATE over more rows than the transaction actually intends to modify.

Diagnosing Recurring Deadlocks

When deadlocks show up repeatedly in production, look at the database's deadlock log (PostgreSQL logs full lock and query detail when log_lock_waits is on; MySQL exposes SHOW ENGINE INNODB STATUS). The recurring pattern is almost always the same two code paths acquiring the same two resources in opposite order — find those two call sites and fix the ordering, rather than just adding retry logic and hoping.

Common Pitfalls

Treating deadlocks purely as something to retry around, without ever fixing the underlying lock-order conflict, just moves the cost to increased latency and wasted work under load. Assuming an ORM's default query patterns are deadlock-safe is risky — many ORMs issue related updates in whatever order model associations happen to be traversed, which can vary between requests. And forgetting to add retry logic entirely means a deadlock becomes a user-facing error instead of an invisible, automatically-recovered hiccup.

A deadlock isn't a failure of the database — it's the database correctly refusing to let two transactions wait on each other forever. The fix lives in your application's lock ordering, not in disabling detection.

This is genuinely advanced material — understanding it requires comfort with distributed systems failure modes, not just Redis commands.

Why a Single Redis Lock Isn't Enough

A basic lock looks simple:

SET resource:order-42 my-random-value NX PX 30000

This sets the key only if it doesn't exist (NX), with a 30-second expiry (PX) so a crashed client doesn't hold the lock forever. The problem is that this single Redis node is a single point of failure. If it goes down before replicating the write to a replica, and the replica gets promoted to master, another client can acquire the "same" lock — because the new master never saw the key.

The Redlock Algorithm

Redlock solves this by using N independent Redis masters (the reference implementation uses 5), with no replication or coordination between them. A client wanting the lock does the following:

1. Get the current time in milliseconds.
2. Try to acquire the lock on all N instances sequentially, using the same key and a random value, with a small timeout per instance so a down node doesn't stall the whole process.
3. Compute elapsed time. The lock is considered acquired only if the client got the lock on a majority (N/2 + 1) of instances, and the total elapsed time is less than the lock's validity time.
4. If acquired, the effective validity time is the original TTL minus the elapsed time and clock drift.
5. If the lock wasn't acquired, release it on every instance immediately, whether or not that instance thought it succeeded.

Why Majority Matters

Requiring a majority (not all N) means Redlock tolerates the failure of a minority of nodes — with 5 nodes, up to 2 can be down or unreachable and the lock still works correctly, the same fault-tolerance principle behind Raft and Paxos-based systems. It also prevents split-brain: two clients can't both get a majority of 5 nodes simultaneously, because any two majorities of 5 must overlap by at least one node.

The Random Value and Safe Release

Each client generates a unique random value for its lock attempt (not just any placeholder). Releasing the lock must check that the stored value still matches before deleting it, done atomically via a Lua script:

if redis.call("get", KEYS[1]) == ARGV[1] then
    return redis.call("del", KEYS[1])
else
    return 0
end

Without this check, a client could accidentally delete a lock it no longer owns — for example, if its own lock expired and a different client acquired it in the meantime.

Clock Drift: The Real Weakness

Redlock's correctness assumes clocks across the N nodes don't drift too far apart relative to the lock's TTL. If a node's clock jumps forward unexpectedly (a bad NTP sync, a VM pause-and-resume, manual clock changes), that node might expire a lock much earlier than the others believe, opening a window where two clients think they hold the lock simultaneously. This is the core of Martin Kleppmann's well-known critique of Redlock: it depends on real-time clock behavior in ways that are hard to fully guarantee.

Fencing Tokens: The Practical Fix

Even with Redlock done correctly, a paused client (GC pause, VM suspend, network partition) can wake up after its lock has expired and still act as if it holds it — writing to a shared resource after another client has already acquired the lock and moved on. The standard mitigation is a fencing token: a monotonically increasing number returned every time a lock is granted.

Client A acquires lock, gets token 33
Client A pauses (GC, network delay...)
Client A's lock expires
Client B acquires lock, gets token 34
Client B writes to storage, tagging the write with token 34
Client A wakes up, tries to write with token 33
Storage rejects it: 33 < 34 (already saw a higher token)

The protected resource itself — a database, a file store, an API — must be the one enforcing the token check. Redlock alone cannot make this guarantee; it can only reduce the likelihood of two clients believing they hold the lock at once.

When to Use Redlock (and When Not To)

Redlock is a reasonable choice for efficiency locks — cases where a duplicate execution is wasteful but not catastrophic, like preventing the same cron-triggered job from running twice, or coalescing duplicate cache-rebuild requests. It is a risky choice for correctness locks — cases where a duplicate execution corrupts data, like coordinating writes to a financial ledger. For those, use a system with strong consistency guarantees (a consensus-based lock service like ZooKeeper or etcd) combined with fencing tokens enforced by the resource itself, not just Redis.

Common Pitfalls

Using an even number of nodes defeats the majority-quorum logic that makes Redlock resilient — always use an odd number so a majority is unambiguous. Setting per-node acquisition timeouts too high means a single slow node can blow past your lock's TTL before you've even finished the acquisition phase. And treating Redlock as a strict correctness guarantee, rather than a best-effort mutual exclusion mechanism, is the mistake that leads to production incidents — pair it with fencing tokens whenever the operation it protects actually matters.

Redlock reduces the probability of a broken lock; it does not eliminate it. Design your protected operations to survive the case where the lock briefly fails.

Why Clean History Matters

A pull request's commit history isn't just a log — it's documentation. Future developers (including you, in six months) will use git blame and git log to understand why a change was made. A history full of noise makes that archaeology painful.

A clean commit history is a gift to your future self and your reviewers.

The Basic Command

git rebase -i HEAD~5

This opens your last 5 commits in an editor, each prefixed with pick. From here you can reorder lines, or swap pick for one of several rebase commands.

The Rebase Commands

How It Works Under the Hood

Rebase doesn't move commits — it replays them. Git walks your branch's commits one at a time, applying each as a patch on top of the new base, and builds brand-new commit objects (with new SHAs) along the way.

A Real Example

Say your branch has this history before opening a PR:

a1b2c3d WIP
e4f5g6h fix typo
h7i8j9k actually add the feature
k0l1m2n oops forgot a file

Run git rebase -i HEAD~4, then change the plan to:

pick h7i8j9k actually add the feature
fixup k0l1m2n oops forgot a file
fixup a1b2c3d WIP
fixup e4f5g6h fix typo

Save and exit — Git squashes all four into a single, well-described commit.

Editing a Commit Message Mid-Rebase

Mark a commit reword, and after saving the plan, Git will stop and open your editor just for that commit's message:

git rebase -i HEAD~3
# change 'pick' to 'reword' on the line you want to rename
# Git opens your editor — update the message, save, close
# rebase continues automatically

Splitting or Amending a Commit

Mark a commit edit to pause the rebase right after it's applied:

git rebase -i HEAD~3
# mark the target commit as 'edit'

# rebase pauses here — make your changes
git add <file>
git commit --amend

# then continue
git rebase --continue

Handling Conflicts

Since rebase replays commits one by one, conflicts can surface at any step:

# fix the conflicting files
git add <resolved-files>
git rebase --continue

# or bail out entirely and go back to where you started
git rebase --abort

Pushing Rebased History

Because rebase rewrites commit SHAs, a normal git push will be rejected. You need a force push — but use the safer variant:

git push --force-with-lease

--force-with-lease refuses to overwrite the remote branch if someone else has pushed to it since your last fetch, protecting teammates from losing work — unlike a plain --force.

When to Use Which

Use squash when a commit's changes belong with the previous one but the message itself still adds context worth keeping. Use fixup for pure "oops" commits where the message adds nothing. Use reword when the code is fine but the message is misleading or too terse. Use drop for commits that turned out to be dead ends, like an experiment you abandoned.

Common Pitfalls

Never rebase commits that other people have already pulled and built on top of — you'll rewrite history out from under them and create painful merge conflicts on their end. Rebase is for local or PR-branch cleanup before merge, not for branches already shared and built upon. Also double-check your rebase plan before saving; a misplaced drop silently deletes a commit's changes, though git reflog can usually recover it if you catch the mistake quickly.

Interactive rebase rewrites history — that's exactly why it's powerful, and exactly why it should stay confined to branches only you (or your PR) are working on.

Cache-Aside (Lazy Loading)

In cache-aside, the application talks to the cache directly, and the cache stays passive. On a read, the app checks Redis first; on a miss, it loads from the database and populates the cache. Writes go straight to the database, and the cache entry is invalidated (or updated) afterward.

def get_user(user_id):
    cached = redis.get(f"user:{user_id}")
    if cached:
        return json.loads(cached)

    user = db.query("SELECT * FROM users WHERE id = %s", user_id)
    redis.setex(f"user:{user_id}", 3600, json.dumps(user))
    return user

def update_user(user_id, data):
    db.execute("UPDATE users SET ... WHERE id = %s", user_id)
    redis.delete(f"user:{user_id}")  # invalidate, don't update

Write-Through

In write-through, the cache sits in front of the database and owns the write path. Every write goes to the cache first, which synchronously writes through to the database before returning. Reads always come from the cache since it's guaranteed to be up to date.

def update_user(user_id, data):
    db.execute("UPDATE users SET ... WHERE id = %s", user_id)
    redis.setex(f"user:{user_id}", 3600, json.dumps(data))  # update, not invalidate
    return data

How the Two Patterns Differ

Consistency Trade-offs

Cache-aside has a small window where the cache can serve stale data: if two requests race between the database write and the cache invalidation, a reader might get an old value. Write-through avoids this because the cache and database are updated together in the same operation — but that comes at the cost of every write now waiting on two systems instead of one.

Cache-aside optimizes for read throughput and simplicity. Write-through optimizes for consistency at the cost of write latency.

TTL Strategy

Even with write-through, set a TTL as a safety net — bugs, race conditions, and out-of-band database writes (migrations, admin scripts) can all leave the cache holding stale data indefinitely without one.

CACHE_TTL_SECONDS = 3600  # 1 hour

redis.setex(key, CACHE_TTL_SECONDS, value)

A short TTL (minutes) suits volatile data like inventory counts or session state. A longer TTL (hours) suits data that changes rarely, like user profiles or product catalogs.

Handling Cache Stampedes

When a hot key expires, dozens of concurrent requests can all miss the cache at once and hammer the database simultaneously. A simple mitigation is a short-lived lock so only one request repopulates the cache while the rest wait:

def get_user(user_id):
    cached = redis.get(f"user:{user_id}")
    if cached:
        return json.loads(cached)

    lock = redis.set(f"lock:user:{user_id}", "1", nx=True, ex=5)
    if lock:
        user = db.query("SELECT * FROM users WHERE id = %s", user_id)
        redis.setex(f"user:{user_id}", 3600, json.dumps(user))
        redis.delete(f"lock:user:{user_id}")
        return user
    else:
        time.sleep(0.05)
        return get_user(user_id)  # retry, likely a hit now

Write-Behind: A Third Option

Worth knowing, though outside this tip's main comparison: write-behind (write-back) caching writes to Redis immediately and asynchronously flushes to the database later. It gives the lowest write latency but risks data loss if the cache crashes before flushing — generally reserved for high-throughput analytics or logging pipelines, not systems of record.

When to Use Which

Reach for cache-aside when reads vastly outnumber writes and brief staleness is acceptable — product listings, user profiles, configuration data. Reach for write-through when correctness matters more than write speed and you can't tolerate cache/database drift — pricing data, inventory levels, anything downstream systems depend on being accurate.

Common Pitfalls

Forgetting to invalidate the cache on delete, not just update, leaves ghost entries that outlive the data they represent. Using a single global TTL for wildly different data types wastes memory on rarely-changing data and creates stampedes on frequently-changing data with the same expiry window. And treating Redis as a source of truth instead of a cache is a design smell — if losing the cache would lose data, it isn't a cache anymore.

The right caching strategy is the one whose failure mode you can live with: cache-aside fails toward staleness, write-through fails toward latency. Pick based on what your system can actually tolerate.

Every API needs a slightly different shape of the same data: the full User, a public-safe User without the password hash, a form that only updates two fields. Copy-pasting the interface for each case means they drift apart the moment one gets updated. TypeScript's built-in utility types solve this by deriving new types from one source of truth.

The Problem

interface User {
  id: string
  name: string
  email: string
  passwordHash: string
  createdAt: Date
}

// Duplicated, drifts out of sync with User over time
interface PublicUser {
  id: string
  name: string
  email: string
  createdAt: Date
}

Every time User changes, someone has to remember to update PublicUser too. They won't.

Partial<T>: Make Every Field Optional

Perfect for update payloads, where the caller only sends the fields that changed.

function updateUser(id: string, changes: Partial<User>) {
  // changes might be { name: 'New Name' } or { email: '...' }
  return db.users.update(id, changes)
}

Pick<T, K>: Select a Subset of Fields

Use it when you only need a few fields from a larger type — a preview card, a dropdown option.

type UserPreview = Pick<User, 'id' | 'name'>
// { id: string; name: string }

Omit<T, K>: Exclude Specific Fields

The mirror image of Pick — keep everything except what you list. Ideal for stripping sensitive fields before sending a response.

type PublicUser = Omit<User, 'passwordHash'>
// { id: string; name: string; email: string; createdAt: Date }

Now PublicUser always tracks User automatically. Add a field to User, and it shows up in PublicUser without touching this line.

Combining Them

Utility types compose. A "rename form" that only lets you edit the name:

type RenameForm = Partial<Pick<User, 'name'>>
// { name?: string }

How the Types Derive From One Source

When to Use Which

• Partial<T>: PATCH/update payloads, optional config objects, form state before submission.
• Pick<T, K>: previews, dropdown options, anywhere you need a deliberately small, explicit subset.
• Omit<T, K>: stripping sensitive or internal fields (passwords, internal IDs) while keeping everything else in sync automatically.

Common Pitfalls

• Omit with a renamed/removed key silently succeeds — TypeScript won't error if you omit a key that was already removed from the base type, so typos in the key list can go unnoticed. Double-check the literal keys against the source type.
• Partial hides genuinely required fields — a Partial<User> update function can't tell "the caller forgot id" from "the caller doesn't want to change id." Keep required identifiers (like id) outside the Partial wrapper: { id: string } & Partial<Omit<User, 'id'>>.
• Reaching for Record<string, unknown> instead of Pick/Omit throws away type safety entirely — utility types keep the connection to the original shape, a loose Record doesn't.

Derive, don't duplicate. If two types describe the same entity, one of them should be built from the other with Pick, Omit, or Partial — not maintained by hand.

Without rate limiting, one noisy client can degrade an API for everyone else. But the naive approach to rate limiting has a nasty boundary bug that most teams don't discover until production.

The Problem: Fixed Window Counter

The simplest approach counts requests in a fixed time box and resets the counter every period:

// Naive fixed window with Redis
async function isAllowed(userId) {
  const key = `rl:${userId}:${Math.floor(Date.now() / 60000)}` // per-minute bucket
  const count = await redis.incr(key)
  await redis.expire(key, 60)
  return count <= 100 // 100 req/min
}

This looks fine until a client sends 100 requests at 0:59 and another 100 at 1:00 — 200 requests in two seconds, twice the intended limit, simply because they straddle the window boundary.

Token Bucket

A bucket holds up to N tokens. Tokens refill at a fixed rate. Every request consumes one token; if the bucket is empty, the request is rejected. This allows short bursts (up to the bucket size) while still enforcing a strict average rate over time — it's what Stripe and AWS API Gateway use under the hood.

class TokenBucket {
  constructor(capacity, refillPerSecond) {
    this.capacity = capacity
    this.tokens = capacity
    this.refillPerSecond = refillPerSecond
    this.lastRefill = Date.now()
  }

  tryConsume() {
    this.refill()
    if (this.tokens < 1) return false
    this.tokens -= 1
    return true
  }

  refill() {
    const now = Date.now()
    const elapsedSeconds = (now - this.lastRefill) / 1000
    this.tokens = Math.min(this.capacity, this.tokens + elapsedSeconds * this.refillPerSecond)
    this.lastRefill = now
  }
}

Sliding Window Counter

A cheaper alternative to a full sliding log: weight the previous window's count by how much of it still "overlaps" the current moment.

// weighted average of previous + current fixed windows
const weight = 1 - (elapsedInCurrentWindow / windowSize)
const estimatedCount = previousWindowCount * weight + currentWindowCount

This smooths out the boundary burst problem without the memory cost of storing a timestamp per request.

How a Rate-Limited Request Flows

When to Use Which

• Fixed window: simplest to implement, fine for coarse per-day/per-hour limits where bursts don't matter.
• Token bucket: the default choice for public APIs — allows reasonable bursts while holding a strict average rate.
• Sliding window: most accurate under sustained load, worth the extra complexity for strict SLAs or billing-sensitive limits.

Common Pitfalls

• Limiting by IP alone breaks for users behind shared NAT or corporate proxies — key on API key or user ID as well as IP.
• Skipping rate-limit headers (X-RateLimit-Remaining, Retry-After) forces clients to guess when they can retry, causing thundering-herd retries.
• Per-instance in-memory counters in a multi-server deployment mean each instance enforces the limit independently — a client can get N times the intended limit by hitting N different instances. Always back the counter with a shared store like Redis.
• Not rate-limiting authentication endpoints separately — login/signup routes need tighter limits than general API traffic to slow down credential stuffing.

Start with a token bucket backed by Redis. It's simple to reason about, allows reasonable bursts, and the same primitive scales from a single endpoint to a full API gateway.

In the Next.js App Router (13+), every component is a Server Component by default. This is a big shift from the old Pages Router, and it's the single most misunderstood part of modern Next.js.

The Problem

Most developers coming from Create React App or the Pages Router slap 'use client' at the top of every file "just in case." That defeats the purpose of Server Components: you end up shipping the same amount of JavaScript to the browser as before, just with extra steps.

Server Components (the default)

Server Components render only on the server. No JS for them is sent to the browser. They can await data directly, touch a database, or use secrets safely, because that code never leaves the server.

// app/products/page.tsx
export default async function ProductsPage() {
  const res = await fetch('https://api.example.com/products', {
    next: { revalidate: 60 },
  })
  const products = await res.json()

  return (
    <ul>
      {products.map((p: { id: string; name: string }) => (
        <li key={p.id}>{p.name}</li>
      ))}
    </ul>
  )
}

No useState, no useEffect, no event handlers here — and no client-side fetch waterfall either.

Client Components ('use client')

Client Components are needed for interactivity: hooks, event listeners, browser-only APIs (window, localStorage), or third-party libraries that rely on the DOM.

'use client'

import { useState } from 'react'

export default function LikeButton() {
  const [liked, setLiked] = useState(false)

  return (
    <button onClick={() => setLiked(!liked)}>
      {liked ? 'Liked' : 'Like'}
    </button>
  )
}

The 'use client' directive marks the boundary — everything imported below it also ships to the browser, so keep these components small and push them to the leaves of the tree.

How Rendering Actually Flows

On every request, the flow looks like this:

Two things happen in parallel once the response lands: the static HTML paints right away (fast first contentful paint), and only the Client Component "islands" get hydrated with JS. The Server Component output is never re-executed or hydrated in the browser.

When to Use Which

• Server Component (default): fetching data, reading from a database, using API keys/secrets, rendering static or mostly-static UI, reducing bundle size.
• Client Component ('use client'): useState/useReducer, useEffect, event handlers (onClick, onChange), browser APIs, context providers, third-party UI libraries that touch the DOM.

Common Pitfalls

• Marking a whole page 'use client' because of one interactive button — push 'use client' down to that button only, not the entire page.
• Importing a Server Component into a Client Component doesn't work the way you'd expect — pass the Server Component in as children or a prop instead of importing it directly.
• Fetching secrets inside a Client Component leaks them into the browser bundle. Keep API keys and DB calls in Server Components only.
• Forgetting next: { revalidate } on fetch calls, which silently opts routes into fully static rendering when you actually wanted fresh data.

Default to Server Components everywhere. Only add 'use client' at the smallest leaf component that truly needs interactivity — your bundle size (and your users) will thank you.

Debounce: wait until the storm passes

A debounced function delays running until events stop coming for a set period. Every new event resets the timer, so it fires only once, after things go quiet.

Use it when you only care about the final state:

• Search-as-you-type (call the API after the user stops typing)
• Validating a field after the user finishes editing
• Autosaving a draft once edits pause

function debounce(fn, delay = 300) {
  let timer;
  return (...args) => {
    clearTimeout(timer);
    timer = setTimeout(() => fn.apply(this, args), delay);
  };
}

const search = debounce((q) => fetch(`/api/search?q=${q}`), 300);
input.addEventListener('input', (e) => search(e.target.value));

Type "laravel" quickly and only one request goes out — 300 ms after the last keystroke.

Throttle: run at a steady rate

A throttled function runs at most once per interval, no matter how many events fire. It doesn't wait for quiet — it guarantees a regular cadence.

Use it when you want periodic updates during a continuous stream:

• Updating a scroll-progress bar
• Recomputing layout on resize
• Rate-limiting rapid clicks

function throttle(fn, interval = 200) {
  let last = 0;
  return (...args) => {
    const now = Date.now();
    if (now - last >= interval) {
      last = now;
      fn.apply(this, args);
    }
  };
}

const onScroll = throttle(() => updateProgressBar(), 200);
window.addEventListener('scroll', onScroll);

Scroll for 3 seconds and the bar updates ~15 times (every 200 ms), not on all 100+ scroll events.

Which one do you need?

Ask yourself: do you want the result after activity settles, or during it?

• "After it settles" → debounce (search, autosave, validation).
• "At a steady rate while it happens" → throttle (scroll, resize, drag).

In production, reach for a battle-tested implementation like lodash.debounce / lodash.throttle — they handle leading/trailing edges, cancellation, and maxWait for you.

A query that feels instant on 1,000 rows can crawl on 1,000,000. The usual reason: the database is doing a full table scan — reading every row to find the few you asked for. An index fixes that.

Without an index: a full table scan

SELECT * FROM users WHERE email = 'ann@example.com';

With no index on email, the engine reads every row and compares email. On a large table that is O(n) work.

With an index: a lookup

CREATE INDEX idx_users_email ON users (email);

An index is a sorted structure (usually a B-tree). The engine now navigates straight to the matching rows in about O(log n) — a handful of reads instead of millions.

Read the plan with EXPLAIN

EXPLAIN SELECT * FROM users WHERE email = 'ann@example.com';

• type = ALL (and "Using where") means a full scan — slow.
• type = ref or const with a key listed means the index is used — good.

Composite indexes follow a left-to-right rule

CREATE INDEX idx_orders_user_status ON orders (user_id, status);

This helps WHERE user_id = ? and WHERE user_id = ? AND status = ?, but not WHERE status = ? on its own — a query must use a left prefix of the indexed columns.

When an index does NOT help

• WHERE YEAR(created_at) = 2026 — wrapping the column in a function defeats the index. Use a range instead: created_at >= '2026-01-01' AND created_at < '2027-01-01'.
• LIKE '%term' with a leading wildcard cannot use a normal index.
• Very low-selectivity columns (like a boolean) — a scan is sometimes cheaper than the index.

Key takeaways

• No index means a full scan (O(n)); the right index means a lookup (O(log n)).
• Index the columns you filter, join and sort on — not every column (indexes cost writes and storage).
• Use EXPLAIN to confirm the index is actually used.
• Keep filters sargable: never wrap an indexed column in a function.

SQL injection is one of the most dangerous security vulnerabilities. Here's how to prevent it.

❌ Never Do This

// VULNERABLE CODE - DO NOT USE!
$userId = $_GET['id'];
$query = "SELECT * FROM users WHERE id = $userId";
$result = mysqli_query($conn, $query);

An attacker can inject: ?id=1 OR 1=1 to access all records!

✅ Use Prepared Statements (MySQLi)

$userId = $_GET['id'];
$stmt = $conn->prepare("SELECT * FROM users WHERE id = ?");
$stmt->bind_param("i", $userId);
$stmt->execute();
$result = $stmt->get_result();

✅ Use PDO with Prepared Statements

$userId = $_GET['id'];
$stmt = $pdo->prepare("SELECT * FROM users WHERE id = :id");
$stmt->execute(['id' => $userId]);
$user = $stmt->fetch();

✅ Laravel Query Builder (Automatic Protection)

$userId = request('id');
$user = DB::table('users')->where('id', $userId)->first();
// or
$user = User::find($userId);

Warning: Raw Queries

Even in Laravel, be careful with raw queries:

// ❌ Still vulnerable
DB::select("SELECT * FROM users WHERE id = " . $userId);

// ✅ Use bindings
DB::select("SELECT * FROM users WHERE id = ?", [$userId]);

Best Practices

1. Always use parameterized queries
2. Never concatenate user input into SQL
3. Use ORM/Query builders when possible
4. Validate and sanitize input
5. Apply principle of least privilege to database users

Real-World Impact

In 2023, SQL injection attacks accounted for 30% of all web application breaches.

Don't be a statistic - protect your applications!

Multi-stage builds allow you to create smaller, more secure Docker images by separating build and runtime environments.

The Problem

Traditional Dockerfile includes build tools in the final image:

FROM node:18
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build
CMD ["node", "dist/index.js"]

Result: ~1GB image with unnecessary build dependencies!

The Solution: Multi-Stage Build

# Build stage
FROM node:18 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Production stage
FROM node:18-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/index.js"]

Result: ~200MB image with only runtime dependencies!

Benefits

• Smaller images: 5-10x size reduction
• Faster deployments: Less data to transfer
• Better security: Fewer attack surfaces
• Cleaner production: No build tools in production

For Laravel Applications

# Composer dependencies
FROM composer:2 AS composer
WORKDIR /app
COPY composer.* ./
RUN composer install --no-dev --optimize-autoloader

# Node assets
FROM node:18 AS node
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Production
FROM php:8.3-fpm-alpine
WORKDIR /var/www
COPY --from=composer /app/vendor ./vendor
COPY --from=node /app/public/build ./public/build
COPY . .

Flow Diagram

Multi-stage builds are a Docker best practice that every developer should use!

PHP 8.4 introduces property hooks, a powerful feature that allows you to add custom logic when getting or setting properties.

Basic Example

class User
{
    public string $name {
        get => strtoupper($this->name);
        set => ucfirst($value);
    }
}

$user = new User();
$user->name = 'john doe';
echo $user->name; // Output: JOHN DOE

Computed Properties

Create virtual properties without backing storage:

class Rectangle
{
    public function __construct(
        public float $width,
        public float $height
    ) {}

    public float $area {
        get => $this->width * $this->height;
    }
}

Validation in Setters

class Product
{
    private float $_price;

    public float $price {
        get => $this->_price;
        set {
            if ($value < 0) {
                throw new InvalidArgumentException('Price must be positive');
            }
            $this->_price = $value;
        }
    }
}

Benefits

• ✅ Cleaner than __get() and __set() magic methods
• ✅ Better IDE support and static analysis
• ✅ More explicit and readable code
• ✅ Type-safe property access

Property hooks make PHP objects more powerful while maintaining backward compatibility!

When working with Laravel's Eloquent ORM, one of the most common performance killers is the N+1 query problem. It appears the moment you load a collection of models and then touch a relationship inside a loop.

The N+1 problem

$posts = Post::all();            // 1 query

foreach ($posts as $post) {
    echo $post->author->name;    // +1 query PER post
}

Load 50 posts and you fire 51 queries: one for the posts, plus one for every author. It is invisible in code review but deadly under load.

The fix: eager loading with with()

$posts = Post::with('author')->get();   // 2 queries total

foreach ($posts as $post) {
    echo $post->author->name;            // no extra queries
}

Laravel runs one query for posts and a single WHERE author_id IN (...) for all authors - 2 queries no matter how many posts.

Nested & multiple relationships

// Multiple relations
$posts = Post::with(['author', 'comments'])->get();

// Nested relations (dot notation)
$posts = Post::with('comments.user')->get();

// Constrain a relation with a closure
$posts = Post::with(['comments' => fn ($q) => $q->latest()->limit(5)])->get();

Load only the columns you need

$posts = Post::with('author:id,name')->get();

Selecting id,name keeps the payload small - just always include the foreign key (id) or the relation will not match.

Eager load after the fact

Already have the collection? Load relationships afterwards with load():

$posts = Post::all();
$posts->load('author');

Catch N+1 automatically

Enable strict mode in a service provider so lazy loading throws during development:

use Illuminate\Database\Eloquent\Model;

Model::preventLazyLoading(! app()->isProduction());

Key takeaways

• with() eager-loads upfront (2 queries); load() eager-loads an existing collection.
• Always eager-load any relationship you touch inside a loop.
• Use column selection and closures to load only what you need.
• Turn on preventLazyLoading in dev to catch N+1 before it ships.

Modern JavaScript uses async/await for handling asynchronous operations. Here are the best practices:

1. Always Handle Errors

async function fetchUserData(userId) {
    try {
        const response = await fetch(`/api/users/${userId}`);
        const data = await response.json();
        return data;
    } catch (error) {
        console.error('Failed to fetch user:', error);
        throw error;
    }
}

2. Parallel Execution

Don't await in sequence when you can run in parallel:

// ❌ Slow - Sequential
const user = await fetchUser();
const posts = await fetchPosts();
const comments = await fetchComments();

// ✅ Fast - Parallel
const [user, posts, comments] = await Promise.all([
    fetchUser(),
    fetchPosts(),
    fetchComments()
]);

3. Promise.allSettled for Independent Operations

const results = await Promise.allSettled([
    fetchUser(),
    fetchPosts(),
    fetchComments()
]);

results.forEach(result => {
    if (result.status === 'fulfilled') {
        console.log('Success:', result.value);
    } else {
        console.log('Error:', result.reason);
    }
});

4. Avoid Async in Loops

// ❌ Bad
for (const id of userIds) {
    await processUser(id);
}

// ✅ Good
await Promise.all(userIds.map(id => processUser(id)));

Key Takeaways

• Always use try/catch for error handling
• Use Promise.all() for parallel operations
• Consider Promise.allSettled() for independent tasks
• Avoid awaiting inside loops

Async/await makes asynchronous code look synchronous, but understanding Promises is still crucial!