Junior Fullstack Developer Interview Preparation Guide - FAANG Standard

Direct answer

A grid of land ('1') and water ('0') cells is an implicit graph where each land cell is a node connected to its up-to-four orthogonal land neighbors; counting islands is counting connected components. Scan every cell in row-major order, and each time an unvisited '1' is found, that is a brand-new island: run depth-first search (DFS) or breadth-first search (BFS) from it to mark every reachable land cell as visited, so the outer scan never counts the same island twice.

Structured elaboration

In-place marking versus a visited set. Flipping a visited land cell from '1' to '0' directly in the grid is the simplest way to mark it: no extra memory beyond the traversal's own stack or queue, but it destroys the caller's input, which is unacceptable if the grid needs to be reused or read again afterward. A separate visited boolean matrix (or a set of coordinates) avoids mutating the input at the cost of $O(R \times C)$ extra memory. The choice is a straightforward trade: mutate for memory efficiency when the caller has explicitly handed over ownership of the grid, use a visited structure otherwise.

Handling non-rectangular (jagged) input. A grid is not guaranteed to have every row the same length; bounds-checking a candidate neighbor must check against THAT row's own length (c < len(grid[r])), not a single global column count, or a jagged grid can silently index out of bounds on a shorter row.

Worked example

from typing import List

def num_islands(grid: List[List[str]]) -> int:
    if not grid or not grid[0]:
        return 0
    rows = len(grid)

    def in_bounds(r, c):
        return 0 <= r < rows and 0 <= c < len(grid[r])

    islands = 0
    for r in range(rows):
        for c in range(len(grid[r])):
            if grid[r][c] == '1':
                islands += 1
                stack = [(r, c)]
                grid[r][c] = '0'  # mark on discovery, in place
                while stack:
                    x, y = stack.pop()
                    for dx, dy in ((1, 0), (-1, 0), (0, 1), (0, -1)):
                        nx, ny = x + dx, y + dy
                        if in_bounds(nx, ny) and grid[nx][ny] == '1':
                            grid[nx][ny] = '0'
                            stack.append((nx, ny))
    return islands

if __name__ == "__main__":
    grid1 = [
        list("11000"),
        list("11000"),
        list("00100"),
        list("00011"),
    ]
    print("grid1 islands:", num_islands([row[:] for row in grid1]))

    print("empty grid:", num_islands([]))

    jagged = [list("10"), list("111"), list("0")]
    print("jagged grid islands:", num_islands([row[:] for row in jagged]))

    all_water = [list("000"), list("000")]
    print("all water:", num_islands([row[:] for row in all_water]))

    def num_islands_bfs_reference(grid):
        from collections import deque
        if not grid or not grid[0]:
            return 0
        rows = len(grid)
        visited = [[False] * len(row) for row in grid]
        count = 0
        for r in range(rows):
            for c in range(len(grid[r])):
                if grid[r][c] == '1' and not visited[r][c]:
                    count += 1
                    q = deque([(r, c)])
                    visited[r][c] = True
                    while q:
                        x, y = q.popleft()
                        for dx, dy in ((1, 0), (-1, 0), (0, 1), (0, -1)):
                            nx, ny = x + dx, y + dy
                            if 0 <= nx < rows and 0 <= ny < len(grid[nx]) and grid[nx][ny] == '1' and not visited[nx][ny]:
                                visited[nx][ny] = True
                                q.append((nx, ny))
        return count

    ref = num_islands_bfs_reference([row[:] for row in grid1])
    print("Matches independent, non-mutating BFS reference:", ref == num_islands([row[:] for row in grid1]))

Output (actually executed with python3):

grid1 islands: 3
empty grid: 0
jagged grid islands: 1
all water: 0
Matches independent, non-mutating BFS reference: True

grid1 has three islands by hand-count: the 2x2 block in the top-left, the single cell at (2,2), and the two-cell block at (3,3)-(3,4). The jagged grid ["10","111","0"] has one island, since (0,0) connects vertically to (1,0), which connects horizontally to (1,1) and (1,2), all four cells joined into one component despite the rows having different lengths.

Complexity

Time $O(R \times C)$: the outer double loop visits every cell once, and the inner DFS/BFS, across the entire run, visits every land cell exactly once (each is marked immediately on discovery, never re-pushed). Space $O(R \times C)$ worst case for the traversal stack (a grid that is entirely one giant island) in the in-place version, or $O(R \times C)$ for the visited matrix plus the stack in the non-mutating version.

Edge cases

• Empty grid, or a grid whose first row is empty: not grid or not grid[0] catches both and returns 0.
• Non-rectangular (jagged) rows: handled by checking each candidate neighbor's bound against that specific row's own length, not a shared column count, as shown above.
• All water: the outer loop never finds a '1', returns 0 without ever starting a traversal.
• A single-cell island, or the entire grid being one connected island: both fall out naturally from the same code path with no special-casing.
• Diagonal adjacency: not counted by this implementation (only the four orthogonal directions), matching the standard problem definition; if diagonal adjacency were required, adding the four diagonal offsets to the direction list is the only change needed, and doing so can only merge islands, never split them, so the count can only decrease or stay the same relative to orthogonal-only adjacency.

Trade-offs and pitfalls

• Recursion depth at scale. A naive recursive DFS on a very large, single-island grid (for example 10,000 x 10,000, all land) recurses as deep as the island's longest simple path, which can exceed a language's default recursion limit; the iterative, explicit-stack version above sidesteps this entirely, which is why it is written iteratively rather than as a simpler-looking recursive function.
• Common mistake: checking visited (or flipping to '0') only when a cell is POPPED from the stack rather than when it is first discovered and PUSHED. This lets the same cell be pushed multiple times by different neighbors before any of those pushes gets processed, wasting work and, in pathological cases, inflating the stack far beyond the actual number of distinct cells.
• Common mistake: using a single shared column-count bound check on a grid that is not actually rectangular, which either throws an index error on a shorter row or, worse, silently reads stale data from a previous row's memory layout depending on the language and data structure.
• Diagonal-connectivity as a difficulty-bump variant. Making 4-direction versus 8-direction connectivity a runtime parameter (rather than hardcoded) is a natural follow-up: the algorithm's shape does not change, only the directions list does, but it is worth naming explicitly since some interviewers use it specifically to see whether a candidate treats "island" as a fixed rule or a configurable one.

What I would change before shipping
For production, I would remove recursion from any traversal or path algorithm that could see a deep tree. An explicit stack is safer than trying to raise Python's recursion limit, because sys.setrecursionlimit only hides the risk and can still crash the process on very deep inputs.

Concrete changes

• Replace recursive traversals with iterative versions.
• Use explicit stacks for inorder, postorder, and path-sum checks.
• Add tests for degenerate trees, such as a single chain of 20,000 nodes.
• Decide what to do on missing nodes or empty trees, and return that consistently.
• Add observability, such as logging maximum depth seen in production.

Example
If a customer uploads a tree shaped like a linked list, a recursive path-sum solution may fail even though the logic is correct. An iterative DFS with (node, state) pairs avoids that failure mode.

Production rule
My default is: if input depth is unbounded, do not rely on recursion. Use iterative code and make memory use predictable.

Direct answer

A hash map alone gives $O(1)$ key lookup but has no notion of access order, so evicting the least-recently-used (LRU) entry would mean scanning every entry to find it, which is $O(n)$. Pairing the hash map with a doubly linked list solves this: the hash map maps each key directly to its node in the list, and the list keeps nodes ordered by recency, most-recently-used at the head and least-recently-used at the tail, so a lookup, a reorder-on-access, and an eviction (pop the tail) are all $O(1)$.

Approach

• Maintain a doubly linked list of nodes (key, value), ordered by recency, with dummy head and tail sentinels so inserting or removing at either end never has to special-case an empty list.
• Maintain a hash map from key to the node holding that key, so you never search the list by value; you always jump straight to the node.
• get(key): if the key isn't in the map, return the miss sentinel. Otherwise move that node to the front (most-recently-used position) and return its value.
• put(key, value): if the key exists, update its value and move it to the front. Otherwise create a new node, add it to the front, and if that pushes the map over capacity, remove the node just before the tail sentinel (the actual least-recently-used entry) and delete it from the map too.

class Node:
    __slots__ = ("key", "value", "prev", "next")

    def __init__(self, key=None, value=None):
        self.key = key
        self.value = value
        self.prev = None
        self.next = None


class LRUCache:
    def __init__(self, capacity: int):
        self.capacity = capacity
        self.map: dict[int, Node] = {}
        self.head = Node()
        self.tail = Node()
        self.head.next = self.tail
        self.tail.prev = self.head

    def _remove(self, node: Node) -> None:
        node.prev.next = node.next
        node.next.prev = node.prev

    def _add_to_front(self, node: Node) -> None:
        node.next = self.head.next
        node.prev = self.head
        self.head.next.prev = node
        self.head.next = node

    def get(self, key: int) -> int:
        if key not in self.map:
            return -1
        node = self.map[key]
        self._remove(node)
        self._add_to_front(node)
        return node.value

    def put(self, key: int, value: int) -> None:
        if self.capacity <= 0:
            return
        if key in self.map:
            node = self.map[key]
            node.value = value
            self._remove(node)
            self._add_to_front(node)
            return
        node = Node(key, value)
        self.map[key] = node
        self._add_to_front(node)
        if len(self.map) > self.capacity:
            lru = self.tail.prev
            self._remove(lru)
            del self.map[lru.key]


if __name__ == "__main__":
    cache = LRUCache(2)
    cache.put(1, 1)
    cache.put(2, 2)
    print(cache.get(1))   # 1 (1 is now most recent)
    cache.put(3, 3)       # capacity 2: evicts key 2 (least recently used)
    print(cache.get(2))   # -1
    cache.put(4, 4)       # evicts key 1
    print(cache.get(1))   # -1
    print(cache.get(3))   # 3
    print(cache.get(4))   # 4

Running this prints, in order: 1, -1, -1, 3, 4, which matches the standard LRU trace (put 1, put 2, get 1 promotes key 1, put 3 evicts key 2 since it's now the least recent, put 4 evicts key 1 since 3 was inserted more recently).

Key points

• Every present key has exactly one node in the map and exactly one node in the list; those two structures are kept in lockstep on every operation.
• The head and tail sentinels remove every edge-case branch for "the list is empty" or "the list has one element" from _remove and _add_to_front.
• Deterministic cache keys: the map key must be a stable, complete representation of the thing being cached. If two logically identical requests can hash to different keys, for example because a key is built from an unordered dict or kwargs whose iteration order isn't fixed, or because it omits a parameter that actually affects the result, you get both a spurious cache miss and duplicate storage for what should have been one entry. Build cache keys from a canonical, fully-ordered encoding of every input that affects the output.
• LRU vs. LFU: this design evicts by recency. A least-frequently-used (LFU) policy instead evicts the entry with the smallest access count, which needs a frequency counter per entry plus a way to find the minimum count in $O(1)$ (typically a doubly linked list of frequency buckets, each bucket holding the keys at that frequency). LFU is worth reaching for when recency is a noisy signal, for example a periodic bulk scan that touches every key once would evict your actual hot set under plain LRU even though those keys are still frequently used elsewhere.

Complexity

Time: $O(1)$ for get and put. Space: $O(n)$ for $n$ cached entries (one hash map entry plus one list node per key).

Edge cases

• capacity <= 0: put is a no-op and get always misses.
• Updating an existing key on put must still move it to the front; forgetting that is the most common bug in this design.
• Capacity of exactly 1: every new put after the first immediately evicts the previous entry.
• A workload dominated by a one-time bulk scan defeats plain LRU by evicting the genuinely hot set; that's the scenario where LFU or a hybrid recency-plus-frequency policy earns its extra bookkeeping.

Direct answer

Design the dashboard around the three failure modes an operator actually needs to distinguish quickly: general degradation (rising latency or falling hit ratio across the board), an emerging hot key (one node/shard diverging from the rest), and eviction-related problems (memory pressure forcing out data that should still be cached).

Structured elaboration

• Panel: cluster-wide health: aggregate hit ratio, miss ratio, and p50/p95/p99 (50th/95th/99th percentile) latency over a rolling window, with the current service-level objective (SLO) target overlaid so a degradation is visible at a glance, not just as a raw number.
• Panel: per-node/per-shard breakdown: CPU, request rate, and latency broken out by individual node, specifically because an emerging hot key looks fine in the aggregate panel but shows one node's line diverging sharply from the others; this panel is what actually catches a hot key before it becomes an incident.
• Panel: eviction and memory: eviction rate and memory usage as a percentage of the configured limit, ideally split by key class or namespace if the cache is shared across use cases, so a memory-pressure problem can be traced to which data is actually filling the cache.
• Alert conditions for degradation: hit ratio dropping below a sustained threshold (e.g., more than 15 points below the trailing 7-day baseline for more than 2 consecutive 5-minute windows) or p99 latency exceeding the SLO target for a sustained period.
• Alert conditions for a hot key: any single node's request rate or CPU exceeding a set multiple (e.g., 3x) of the cluster's median node, sustained for more than a short window (to avoid alerting on normal brief variance).
• Alert conditions for eviction problems: eviction rate rising sharply relative to its own recent baseline, especially combined with memory usage near the configured limit, distinguishing "the cache is working as intended, evicting genuinely cold data" from "the cache is thrashing, evicting data that will be needed again soon."

Worked example

A hot-key alert fires when node 7's request rate is 4x the cluster median for more than 60 seconds; the dashboard's per-node panel immediately shows node 7 as a clear outlier against otherwise-flat lines for the other nodes, letting the on-call engineer confirm within seconds that this is a hot-key event rather than a cluster-wide issue, and start the hot-key mitigation runbook instead of investigating a broader outage.

Trade-offs and pitfalls

A dashboard that only shows cluster-wide aggregates cannot distinguish a hot-key problem from general health, which is exactly the failure mode this design targets; do not skip the per-node breakdown panel to save dashboard space. Alerting on eviction rate alone without memory context conflates "healthy, expected eviction" with "the cache is undersized"; always pair eviction-rate alerting with memory-utilization context.

Direct answer

Latency is how long a single request takes from request to response; throughput is how many requests the system completes per unit time. They are related through concurrency: at a fixed level of concurrency, throughput is roughly concurrency divided by latency, so throughput can be raised either by lowering per-request latency or by running more requests concurrently, at least until the system runs out of capacity, at which point requests start queueing and both latency and its variance rise sharply.

Structured elaboration

Little's Law is the bridge between the two

$L = \lambda W$

where L is the average number of requests in the system (concurrency), lambda is the arrival rate (throughput), and W is the average time each request spends in the system (latency). This one relationship connects the two metrics completely.

Two regimes

• Below capacity: adding concurrency raises throughput roughly linearly without raising latency much, since the extra work overlaps with idle capacity.
• Near or above capacity: requests start queueing behind each other, and latency rises non-linearly. A small increase in load causes a disproportionate jump in the tail, a pattern basic queueing models (for example M/M/1: the standard textbook queueing model for one server with random arrivals and random service times, the model that produces the classic curve where wait time explodes as utilization approaches 100%, named here, not derived) predict and production systems reliably show.

Why percentiles, not the average, matter once load is near capacity
The mean can look fine while a growing minority of requests wait behind a queue; the 95th and 99th percentile (P95/P99) surface exactly what the average hides.

The two are not always aligned
Batching, processing many items in one call to raise throughput, typically raises the latency of any individual item in the batch. A system tuned to maximize throughput at all costs (large batches, very high concurrency) can make its own P99 latency worse, which is why the metric worth optimizing depends on the workload: a public, user-facing API should optimize for tail latency at a given throughput target; an overnight batch job should optimize for total throughput and mostly ignore any single item's latency.

Worked example

Suppose a service's actual processing time per request (its service time) is 10 ms, and the target is 500 requests/sec sustained. Little's Law says the average number of requests being served concurrently at that point is:

$L = \lambda \times W_{service} = 500 \text{ req/s} \times 0.01 \text{ s} = 5 \text{ concurrent requests}$

If the worker pool has exactly 5 workers, the system is running at 100% utilization, and queueing theory's core warning applies: at or near full utilization, queue length and wait time become highly unstable, since there is no slack to absorb any variance in arrival timing or request duration. Sizing to a target utilization of about 75% instead:

$\text{capacity} = \frac{L}{\rho_{target}} = \frac{5}{0.75} \approx 6.7 \Rightarrow 7 \text{ workers}$

gives the system headroom to absorb bursts without its tail latency exploding, at the cost of running roughly 40% more capacity than the bare-minimum number, capacity that sits partly idle most of the time. That headroom is not waste; it is the price of a stable P99.

Beyond the mechanics, defending a capacity decision to non-engineering stakeholders usually means presenting this same relationship visually: a P50/P95/P99 latency trend next to a throughput trend over the same time window, so a viewer can see the point where rising throughput starts dragging tail latency up, rather than being told about it in the abstract.

Trade-offs & pitfalls

• Quoting only an average latency number, which hides that the system may already be close to its queueing knee for a meaningful fraction of requests.
• Treating "increase throughput" and "decrease latency" as the same goal; batching and running near full utilization both raise throughput while making individual-request latency worse.
• Sizing capacity to exactly the average expected load instead of leaving headroom, which looks efficient on a spreadsheet and causes a tail-latency incident on the first genuinely busy day.
• What a senior answer adds: naming which of the two metrics the workload actually cares about, rather than reciting the definitions of latency and throughput and stopping there.

Direct answer. A standard B-tree index stores values in sorted order, which lets it efficiently find a matching PREFIX of a string; a wildcard at the START of a LIKE pattern means there's no fixed prefix to search for, so the index can't narrow the search at all and the engine falls back to checking every row's text against the pattern directly.

Structured elaboration. LIKE 'foo%' (wildcard only at the end) can use a standard B-tree index efficiently, because every string matching that pattern shares the same prefix, 'foo', which the index's sorted order can jump straight to. LIKE '%foo%' or LIKE '%foo' (wildcard at the start) has no such fixed prefix: a match could be any string CONTAINING or ENDING WITH 'foo' anywhere, which the sorted order of a standard index gives no leverage on at all, so the engine has no better option than scanning and checking every row.

Realistic options: a specialized full-text search index (built for token or substring matching rather than prefix matching) is the most direct fix if your engine supports one and the matching semantics fit; a trigram or n-gram index (where supported) can accelerate substring matches specifically, including leading-wildcard patterns, by indexing small overlapping fragments of the text rather than the whole string; and, if the real requirement is closer to "search," moving that specific workload to a dedicated search engine designed for it is often the more durable long-term answer once a standard relational index genuinely can't help.

Worked example. A dashboard filter doing WHERE comments LIKE '%refund%' against a large text column is the exact shape that defeats a plain B-tree index; if the underlying database supports a trigram index, adding one on that column can make this specific kind of substring search dramatically faster without changing the query at all, since the trigram structure is built specifically to handle "the pattern could start anywhere" searches that a standard index can't.

Trade-offs and pitfalls. Specialized indexes for this kind of search (trigram or full-text) cost more storage and more write-time maintenance than a standard B-tree, and aren't a good fit for every use case (very short strings, or a genuinely rare query pattern that doesn't justify the ongoing cost); weigh how often this kind of search actually runs, and how latency-sensitive it is, against that ongoing cost before reaching for a specialized index.

Problematic selector patterns

• Universal selector (*) — forces browser to match every element.
• Deep descendant selectors (A B C) — long scope increases matching work.
• Qualified universal (div ), attribute-heavy selectors ([data-="x"]) and :not() with complex expressions.
• ID/inline style overuse prevents reuse; overly-specific chains harm maintainability.

Why they’re bad

• Browsers match right-to-left; complex selectors make many node tests per element and slow repaint/reflow on large DOMs.

Guidelines

• Prefer class selectors (.btn) and short selector chains.
• Use BEM or utility classes for predictable specificity.
• Limit descendant depth; use direct child (>) sparingly.
• Avoid runtime generated generic attributes; cache computed styles in CSS classes.
• Keep selector count reasonable; reuse styles.

Profiling / spotting bottlenecks

• Use Chrome DevTools Performance + Coverage to find unused/expensive rules.
• In DevTools Elements, toggle rule sets to see repaint impact.
• Measure repaint/reflow (Performance tab: Layout events) while interacting; isolate by disabling suspected rules.
• Audit with Lighthouse and CSS coverage to trim large stylesheets.

Direct answer

Name two or three sources of engagement that are durable, ownership of a real problem, autonomy to fix something broken, seeing your work actually used, because those are what survive a bad day, unlike novelty or initial excitement, which don't.

The framework

1. Separate fragile excitement from durable motivation: prestige, initial novelty, and a strong first impression wear off; ownership of an outcome, autonomy, and a teammate depending on you tend not to.
2. Contrast durable motivators with compensation explicitly: this question is implicitly testing whether your engagement is pay-dependent, if the work is only worth doing because of the paycheck, a bad day has nothing to pull you back, so naming non-comp durable motivators directly answers what's being tested.
3. Acknowledge that bad days are real rather than claiming immunity to them; naming what specifically pulls you through one is more credible than implying you never have them.
4. Tie the durable motivator to something concrete about this specific role's day-to-day, not a generic value that would apply anywhere.

Worked example

On a genuinely hard day earlier in my career, a project I owned hit a frustrating, unglamorous problem that took much longer than planned to actually fix. What got me back in the next morning wasn't excitement about the company, it was that the problem was mine to solve and a teammate was blocked on it; finishing it meant something specific and immediate, not abstract. That's the kind of motivator I'm looking for in this role too: a defined area of ownership where the work is visibly mine and visibly used, not just a mission statement I agree with in the abstract.

Trade-offs and pitfalls

An answer built entirely on external motivators invites the obvious follow-up about leaving for more money, while an answer that claims total immunity to bad days reads as unconvincing; the credible middle ground names something specific that held up under a real bad day.

Direct answer

R(A,B,C,D) with FDs A -> B, B -> C, C -> A, and A -> D has candidate keys {A}, {B}, and {C} (each determines all the others), so the relation is already in 3NF and, once every candidate key is correctly identified, turns out to already satisfy BCNF too; decomposing it is only needed if the FDs instead produced overlapping composite candidate keys, which is the genuinely BCNF-violating shape this exercise is really testing for.

Structured elaboration

Finding the candidate keys. From A -> B, B -> C, C -> A: A, B, and C mutually determine each other (a three-way cycle), so each of {A}, {B}, {C} alone determines the other two of that trio. Combined with A -> D (and by transitivity B -> D and C -> D, since B -> C -> A -> D and similarly for C), each of A, B, C alone determines all four attributes. So the three candidate keys of R are {A}, {B}, and {C}.

Checking normal forms. R is in 3NF: every attribute is either part of some candidate key (A, B, C each are, individually) or fully non-prime and dependent only on a key (D depends on A, a key). Checking BCNF means checking every determinant against every candidate key: A -> B has determinant A, a candidate key; B -> C has determinant B, also a candidate key; C -> A has determinant C, also a candidate key; A -> D has determinant A again. Since A, B, and C are each full candidate keys on their own, EVERY determinant here is in fact a superkey, meaning R as given is already in BCNF, not merely 3NF, once the cyclic candidate keys are correctly found.

Where a genuine BCNF violation would appear. The instructive version of this exercise is when the FDs instead give overlapping composite candidate keys, such as AB -> C, C -> B (candidate keys {A,B} and {A,C}): there, C -> B has C as its determinant, and C alone is NOT a superkey (it doesn't determine A), so that relation is in 3NF but violates BCNF, and decomposing into R1(A,C) and R2(C,B) (projecting on C -> B) removes the violation.

Worked example

For the corrected teaching example (the one that genuinely violates BCNF): course_enrollment(student_id, subject, teacher) with teacher -> subject (each teacher teaches one subject) and candidate key (student_id, subject) (a student takes at most one teacher per subject). teacher is a determinant but not a superkey (it doesn't determine student_id), so this violates BCNF despite being in 3NF. Decompose into teaches(teacher, subject) (projecting the violating dependency) and enrolled(student_id, teacher). Checking losslessness: the common attribute between the two projections is teacher, and teacher is a candidate key of teaches, which is exactly the sufficient condition for a binary decomposition to be lossless (the join of the two projections back on their shared attribute reconstructs the original relation exactly, with no spurious rows).

Checking dependency preservation: teacher -> subject is preserved directly in teaches, but the original dependency (student_id, subject) -> teacher is NOT preserved by this decomposition. Neither teaches nor enrolled alone can enforce it: teaches only constrains (teacher, subject) pairs, and enrolled only constrains (student_id, teacher) pairs, so nothing stops teaches from holding (T1, Math) and (T2, Math) while enrolled holds (S1, T1) and (S1, T2) -- both inserts succeed locally, yet joining the tables shows student S1 taking Math from two different teachers, which is exactly the violation (student_id, subject) -> teacher was supposed to prevent. Detecting this requires a join across both tables; it cannot be checked from either table's own constraints. This is the standard textbook illustration that a BCNF decomposition can be lossless while still failing to preserve every original functional dependency: if enforcing (student_id, subject) -> teacher directly at the schema level matters more than eliminating the redundancy BCNF removes, the usual choice is to stop at a 3NF decomposition instead (3NF decompositions are always both lossless and dependency-preserving), or add an explicit application-level or trigger-based check that re-derives and enforces the dependency across the join, since the decomposed relational schema alone cannot.

Trade-offs and pitfalls

• The instructive point of this exercise is precisely that R(A,B,C,D) as literally stated turns out to already be in BCNF once you correctly identify all three single-attribute candidate keys; the exercise is really testing whether you can find candidate keys from a cyclic set of FDs, not whether you can mechanically apply a BCNF-violation checklist without first doing that work.
• A decomposition can be lossless without being dependency-preserving, or vice versa; BCNF decompositions are always achievable losslessly, but are not always guaranteed to preserve every original functional dependency, which is one of the few cases where 3NF (which always preserves dependencies) is deliberately chosen over BCNF in practice.
• Cyclic functional dependencies like A -> B -> C -> A are a common source of confusion: it's tempting to treat only the "first" attribute in a chain as a key, but every attribute in a determination cycle is equally a candidate key on its own.

Clarify goals & constraints

• Keep UI responsive across tabs, minimize latency, preserve security (avoid XSS/CSRF risks), and have deterministic conflict resolution when two tabs update the same state (e.g., cart, auth).

APIs to use

• BroadcastChannel (primary inter-tab signalling — low latency)
• localStorage events (fallback for older browsers)
• Service Worker (for background sync with server)
• IndexedDB (durable, large structured state)
• Navigator.sendBeacon / fetch for server sync

Overall strategy

1. Single source of truth: server is authoritative. Tabs keep a local cache (IndexedDB).
2. Update flow: user action → optimistic local update → write to IndexedDB + broadcast a compact operation over BroadcastChannel (includes op, payload, meta).
3. Server reconciliation: send operation to server; server applies, returns canonical state or op-ack.
4. Finalize: on server ack, tabs update local cache and UI. If server rejects, broadcast rollback op.

Conflict resolution (deterministic)

• Use Lamport timestamps plus stable tabId:
  • Each op carries {tabId, lamportCounter, opId}.
  • Compare by lamportCounter then tabId to break ties (lexicographic).
• For convergent CRDT-friendly domains (shopping cart), use simple CRDTs (observed-remove set + quantities) to ensure eventual consistency without central rollback.

Race handling & performance

• Coalesce rapid ops per tab (debounce + batching).
• Keep broadcasts lightweight (operation diffs, not full state).
• Use Service Worker for background sync retries; fall back to periodic reconciliation (on focus, network reconnect).

Security

• Do NOT store auth tokens in localStorage. Use HTTP-only, Secure, SameSite cookies for auth. For auth status propagation, broadcast only a boolean/state nonce — avoid secrets.
• Sanitize any data that may be rendered; use CSP and input validation.
• Verify origin in BroadcastChannel handlers and ignore malformed ops.
• On sensitive ops, require server-side verification (CSRF tokens, double-submit cookie if using non-HTTP-only tokens).

Example determinism rule

• Apply op A before B if:
  • A.lamport < B.lamport OR
  • A.lamport == B.lamport AND A.tabId < B.tabId

Edge cases

• Offline: record ops in IndexedDB, broadcast locally, retry via SW when online.
• Tab crash: other tabs will reconcile via server on next heartbeat or focus.
• Large state: sync diffs; provide snapshot checkpoints occasionally.

This approach balances responsiveness, security, and determinism: server authority + optimistic local ops + Lamport+tabId deterministic ordering (or CRDTs where applicable), BroadcastChannel for fast propagation, IndexedDB for durability, and Service Worker for reliable server sync.