Google Backend Developer (Staff Level) - Comprehensive Interview Preparation Guide

Direct answer
Restate the instruction in your own words as a quick confirmation before acting, framed as checking your own understanding rather than doubting them, so it reads as diligence rather than not having listened.

Structured elaboration

• Frame it as confirming your own plan, not re-asking their request. "Just to make sure I act on the right thing, my plan is to do X, does that match what you meant?" reads very differently from "wait, what did you want again?"
• Be specific in the paraphrase, not generic. A vague paraphrase ("okay, got it, I'll handle it") gives them nothing to correct if you actually misunderstood; a specific one gives them an easy, fast way to say "actually, no" if needed.
• Do it briefly and move on. One sentence of confirmation, not a lengthy negotiation over wording; the goal is a fast check, not a renegotiation of the request.
• If genuinely rushed, confirm asynchronously right after rather than not at all: a one-line follow-up message restating what you understood, sent immediately after the quick instruction, still catches a misunderstanding before you've acted on it.

Worked example
Instruction given quickly in passing: "Can you get that report over to finance today?"

Weak version: "Yep, will do." (No confirmation of which report, which finance contact, or what today means if it's late in the day.)

Better version: "On it, I'll send the Q3 variance report to Priya in finance by end of day, that's the one you mean?"

This surfaces, in one sentence, exactly which report, which recipient, and what "today" means, giving them a fast chance to correct any of the three if you guessed wrong, without making them repeat the whole instruction.

Trade-offs and pitfalls

• Doing this for every trivial instruction can come across as needing excessive hand-holding; reserve the explicit paraphrase for instructions with real ambiguity or real consequences if you get it wrong.
• A paraphrase that's too close to a verbatim repeat of their words doesn't actually test whether you understood the intent, only whether you can repeat words back; try to restate it in language that shows you grasped the underlying goal, not just the surface phrasing.
• If they seem rushed or impatient with the confirmation, a very short version ("Q3 report to Priya today, correct?") gets the same benefit with almost no added time.

Direct answer

For chat, global linearizable ordering is rarely worth its cost: it forces every message through one serialization point and makes the whole system unavailable to that point during a network partition, exactly when users still want to keep typing. Causal ordering (order only what a "reply to" relationship actually requires) combined with eventual ordering for everything else is what real chat products converge on, because it is fully available during a partition and matches what users actually notice.

Note on scope: "partitions" below means a network partition in the distributed-systems sense, part of the system temporarily unable to reach another part, not a chat room or a message-queue partition.

Structured elaboration

What each approach is actually protecting. (A) protects a property, one true global sequence, that a chat user has almost no way to perceive directly. (B) protects the one relationship users do notice: a reply appearing to precede the message it replies to. (C) protects nothing about relative order at all, it optimizes purely for "my message appears instantly," and accepts that order can visibly wobble when messages from a temporarily-partitioned participant arrive late.

A practical hybrid. Most real chat systems run (C) as the default for the overall room feed (instant local append, cheap, available) and layer (B) narrowly onto reply chains specifically (a message carries a pointer to what it replies to, and the UI waits for that specific dependency before rendering the reply under it). This gets eventual ordering's latency and availability everywhere, and causal ordering's correctness exactly where users would notice its absence.

Partition keys under the hood. Whichever of (B) or (C) is chosen, if the underlying transport is a partitioned log, using a per-conversation (or per-user, for a social-feed-style variant) partition key is what lets it scale horizontally while keeping a strong-enough guarantee within one conversation's own stream, the same per-entity partitioning technique used for ordering guarantees elsewhere in this topic, not a new idea specific to chat.

Worked example

Two participants, X and Y, are on opposite sides of a brief network partition. X sends message 1 ("are you free at 3pm?"). During the partition, Y (who has not received message 1 yet) sends message 2 ("hey, how's it going?"), unrelated to message 1. Once the partition heals both messages arrive at every client.

• Under (A): neither message could have been finalized while the sequencer was unreachable from X's side; in practice this means send was either blocked (bad experience) or the "global" guarantee was already broken by letting them send locally anyway.
• Under (B): message 2 carries no causal dependency on message 1 (Y never saw it), so it displays as soon as it arrives, no waiting; if Y had instead replied to message 1, that reply would wait to display until message 1 itself had arrived and rendered.
• Under (C): both messages simply append to the local log in whatever order they physically arrive, which may not match either sender's real send order, and for two unrelated messages like this, essentially nobody notices or cares.

Trade-offs and pitfalls

• Choosing (A) "to be safe" without pricing in its latency and partition-availability cost is disproportionate for a surface where users tolerate eventual consistency far more than they tolerate lag, a common pitfall in system-design interviews specifically.
• (C) alone, with no causal layer at all, does produce visible, confusing reorderings for reply threads specifically, that is the one gap worth fixing, not a reason to jump straight to (A).
• Vector clocks under (B) are cheap per conversation but do not scale to "track causal order for every message across every conversation globally," scope them to the conversation or reply-thread level, not system-wide.
• Read receipts, typing indicators, and other presence features layer on top of whichever ordering choice is made; they are a separate design question, not solved by picking (A), (B), or (C).

Direct answer
Decomposing a monolith into many small services shifts operational load from "deploy and operate one thing" to "deploy and operate N things," which multiplies the number of deployment pipelines, the number of places an incident can originate, and the number of services someone needs to be paged for, so the operations model needs to change deliberately (routing, on-call structure, alerting design) rather than simply scaling the old monolith-era practices across more services.

Structured elaboration
Deployment pipelines: a monolith has one pipeline to maintain and improve; N services means N pipelines unless there's a shared, templated deployment approach, so investing in a standard, reusable pipeline template early (rather than letting each service reinvent its own) is what keeps this from becoming N times the maintenance burden. Incident management: with a monolith, on-call needs deep familiarity with one large system; with many services, on-call needs either broad familiarity with many smaller systems (harder to maintain deep expertise in each) or a routing mechanism that pages the specific team owning whichever service is actually failing, which requires accurate service ownership metadata and alerting configured per service rather than one undifferentiated alert stream. On-call rotation: the natural model shifts from one shared rotation covering the whole monolith to per-team rotations, each covering the services that team owns, which requires clear, unambiguous ownership (no orphaned or ambiguously-owned services that nobody is actually on call for).

Worked example
As service count grows, avoiding alert fatigue specifically requires: routing alerts to the team that actually owns the failing service (rather than a single shared on-call rotation getting paged for every service in the fleet, most of which they don't know well), distinguishing service-level-objective (SLO) impacting alerts (a customer-facing symptom worth waking someone up for) from purely internal or low-severity signals (which can wait for business hours or go to a dashboard instead of a page), and periodically reviewing alert volume per service to catch and fix a chronically noisy alert rather than letting on-call engineers learn to ignore it, since an alert that's routinely ignored provides no real protection when it matters.

Trade-offs and pitfalls
The common failure as service count grows is not investing in the operational tooling (service ownership catalog, alert routing, shared pipeline templates) at the same time as the service count grows, so the org ends up with 50 services and still a single undifferentiated on-call rotation and alert stream, which reliably produces alert fatigue and slow incident response, since the person paged often isn't the person who actually understands the failing service. The fix is treating the operations model itself as something that needs deliberate investment alongside the architectural decomposition, not an afterthought that scales itself.

I would split the screen or view model into pure logic and side effects.

First, I’d inject dependencies instead of constructing them: an API client interface, a parser/mapper, and a repository or persistence gateway. The view model should orchestrate state, not know how HTTP or storage works.

A good shape is:

• ViewModel: handles user intent and UI state.
• Use case or service: contains business rules.
• Repository: coordinates remote and local data.
• Data sources: one for API, one for storage.
• Mapper: converts raw DTOs into domain models.

That gives you unit-testable seams. You can test the view model with fake dependencies, verify it emits the right state, and test the repository separately with stubbed API responses or an in-memory store. Parsing should happen in a pure function or mapper, so malformed payload handling can be tested without UI or storage.

This design reduces coupling, makes failures easier to localize, and prevents a single class from becoming impossible to test.

Direct answer: To make eventual consistency between service A and B idempotent and reconciliation-friendly, service A publishes events with a stable event ID (or a monotonic sequence number per entity), service B's consumer deduplicates on that ID before applying any change, and a periodic reconciliation job independently compares A's and B's views to catch and repair anything that slipped through despite the idempotency guarantees.

Structured elaboration

Idempotent event processing on the consumer side. Every event from A carries a stable identifier; B's consumer checks (atomically, alongside applying the event) whether that ID has already been processed, using the same "dedup record plus the actual state change in one transaction" discipline as any idempotent write. This is what makes at-least-once delivery (which any reasonable messaging setup between A and B will actually provide) safe: redelivery is a no-op rather than a duplicate application.

Preserving ordering where necessary. If events for the same entity must be applied in order (e.g. "created" before "updated" before "deleted"), B's consumer needs either a strictly-ordered delivery channel per entity (partition by entity ID) or an explicit sequence number in each event that B checks against the last-applied sequence for that entity, rejecting or buffering an out-of-order arrival rather than applying it prematurely.

Supporting replays. Because B's state can, despite everything, still drift from A's (a bug, an extended outage, a schema-migration mistake), the design should support REPLAYING A's full event history into B from scratch (or from a checkpoint) to rebuild B's view, which requires A to retain (or be able to regenerate) its event history for at least as long as any realistic replay window, and requires B's apply logic to be safe to run repeatedly over the same events (which it already is, by the idempotency design above).

Reconciliation as the safety net, not the primary mechanism. A periodic job independently compares A's and B's data (via checksums, row counts, or a full diff on a schedule appropriate to the data's size and criticality) and either auto-repairs small, well-understood divergences or flags larger ones for human review. This is deliberately a SEPARATE mechanism from the event-driven sync path, its job is to catch failures of that path (a dropped event no retry ever recovered, a bug in the consumer's apply logic), not to be the primary way B stays in sync (that would defeat the point of event-driven propagation in the first place).

Worked example. Service A (an Orders service) publishes OrderUpdated{order_id, sequence, payload} events. Service B (a search index) consumes them, checking (order_id, sequence) against the last sequence it applied for that order, skipping (as an idempotent no-op) any event with a sequence it's already seen or older, and buffering (briefly) any event that arrives out of order, applying it once the gap is filled or timing it out into a "request full replay for this order_id" fallback if the gap doesn't close. Nightly, a reconciliation job compares a sample (or full set, for smaller datasets) of orders between A's source of truth and B's index, flagging any order where B's data doesn't match A's for investigation, this is how the team discovered a bug where B's consumer was silently dropping events during a brief scaling event, well before any customer noticed stale search results.

Trade-offs and pitfalls. Skipping the reconciliation job because "the event pipeline is reliable" is a common and risky shortcut, event-driven consistency mechanisms fail in ways that are often invisible until reconciliation (or a customer complaint) surfaces them, since a missed event usually produces no error, just quietly stale data.

Direct answer. A synchronous call with a long timeout is the simplest contract but scales worst and is the least reliable; asynchronous polling adds one extra round trip per check but is simple, universally supported, and tolerant of client disconnects; a webhook callback removes polling entirely but requires the client to run a reachable, publicly addressable endpoint; and a push mechanism (SSE or WebSockets) gives the lowest latency notification but costs a held-open connection per client and, unlike the other three, loses events outright across a dropped connection unless you deliberately design around it.

Synchronous, long-timeout call. Contract: the client makes one request and the connection stays open until the operation finishes. Simplest to implement and to consume, but it ties up a connection (and, usually, a worker thread or process) on both ends for the full duration, does not survive a client disconnect or a load-balancer's own idle-connection timeout, and gives the client no way to check progress or cancel while waiting. Reasonable only for operations that reliably finish in a few seconds.

Asynchronous polling. Contract: POST starts the job and returns 202 Accepted with a Location header pointing at a status resource; the client GETs that resource repeatedly until it reports a terminal state. Trade-off: an extra round trip per check, and the client has to decide a polling interval (too frequent wastes both sides' resources, too infrequent adds latency to when the client learns of completion), but it needs no special client-side networking capability (any client that can make a plain GET can poll) and survives a client disconnecting and reconnecting later, since the job's state lives independently on the server.

Webhook callback. Contract: the client registers a callback URL at job-submission time; the server POSTs the result to that URL once the job completes, with the usual webhook discipline (signing the payload, retrying on delivery failure, the client acknowledging receipt). Trade-off: removes polling entirely and notifies the client the instant the job finishes, but requires the client to operate a publicly reachable HTTP endpoint capable of receiving the callback reliably, which is a real operational burden a purely client-side application (a mobile app, a browser tab) usually cannot meet at all.

Push (SSE or WebSockets). Contract: the client opens one connection and receives job-status events pushed over it as they happen, no polling and no callback endpoint needed on the client's side. Trade-off: lowest latency notification of the four options, but the server has to hold one open connection per subscribed client for as long as they care about updates, which is real, ongoing resource cost per client (unlike polling, whose cost is bounded and predictable, or webhooks, which cost nothing while nothing is happening) and this cost scales linearly with the number of simultaneously-watching clients, not with how many jobs are actually running. Reliability is the real weak point of this option specifically: if the connection drops mid-job (a mobile network hiccup, a laptop sleeping), any event pushed while disconnected is simply lost, unlike polling (the next poll just re-reads current state) or a webhook (the server retries delivery). SSE mitigates this with a built-in Last-Event-ID mechanism so a reconnecting client tells the server where it left off and missed events can be replayed; a raw WebSocket has no equivalent built in and needs the same idea implemented by hand. In practice, push is usually paired with a fallback GET on the status endpoint after a reconnect, so a client that missed an event still converges on the true state instead of silently believing stale information.

Choosing. Reach for polling as the default (works everywhere, no special client capability required); reach for a webhook when the caller is itself a server-side integration that can reliably host a callback endpoint; reach for push only when true low-latency notification to many simultaneously-connected clients is a real product requirement (a live collaborative dashboard), since it is the option with the highest ongoing server cost per client and the one most in need of an explicit reconnect-and-reconcile plan.

Direct answer. Read the plan tree from the leaves up, note the join algorithm and physical operator at each level, and compare each node's estimated row count to its actual row count; the largest divergence, combined with the node consuming the most time, is almost always where you should focus first.

Structured elaboration. Start by identifying the leaves (the scans) and work upward, tracking, at each join, which side was the "outer/driving" side and which was the "inner/probed" side, and which physical algorithm was used. For each node, note actual time (cumulative, including children) and actual rows versus estimated rows. A join order that puts a large, unfiltered table on the outer side of a nested loop is a red flag; a hash join whose build side turns out much larger than estimated is a sign the memory budget for that hash table may be undersized. Once you've walked the tree once for structure, walk it again purely looking for the single node with the largest gap between estimated and actual rows, since that's usually the root cause the other symptoms trace back to.

Worked example. Suppose a plan shows, from the bottom: a sequential scan on orders with an estimated 50,000 rows and an actual 48,000 rows (a good estimate), feeding into a hash join with customers whose own estimate and actual are both close, but that hash join then feeds a nested loop join against an addresses table where the estimated row count was 10 and the actual was 12,000, executed 1,000 times in a loop. The nested loop's own local estimate wasn't wildly wrong (10 vs 12,000 estimate-vs-actual per iteration is close in absolute terms), but multiplied across 1,000 loop iterations that's the node actually dominating total time, which a glance at just its own row estimate would hide.

Trade-offs and pitfalls. It's easy to anchor on the operator name that "sounds expensive" (hash join, sort) rather than the actual numbers; a hash join over a small, well-estimated input can be nearly free, while a nested loop that LOOKS cheap per iteration can dominate total runtime once you account for how many times it runs. Always multiply per-iteration cost by loop count before deciding a node is innocent.

Direct answer

Each additional nine of availability cuts your allowed downtime by roughly 10x, but the cost to get there does not scale the same way. Moving from 99.9% to 99.99% is mostly "add real redundancy and automate failover," a fairly linear cost increase. Moving from 99.99% to 99.999% is usually "eliminate every remaining shared-fate dependency" (one control plane, one DNS provider, one deploy pipeline), which is a structural and organizational cost, not just more servers.

Where the downtime budget actually goes

First, pin the numbers so "a nine" means something concrete. Availability A translates to allowed annual downtime as:

$$\begin{aligned} D_{99.9\%} &= (1-0.999)\times 365.25\times 24\times 60\ \text{min} = 525.96\ \text{min} \approx 8.76\ \text{h/yr} \\ D_{99.99\%} &= (1-0.9999)\times 525960\ \text{min} = 52.60\ \text{min/yr} \\ D_{99.999\%} &= (1-0.99999)\times 525960\ \text{min} = 5.26\ \text{min/yr} \end{aligned}$$

So the jump from three nines to four nines removes about 7.9 hours of allowed downtime a year; the jump from four to five nines only removes about 47 more minutes. The absolute engineering effort per nine goes up even as the remaining slack shrinks, because what's left to fix gets harder to reach.

Second, understand why redundancy has diminishing structural cost, not diminishing dollar cost. If a single component (one instance, one AZ) has availability $a$, and you put $N$ independent, truly uncorrelated redundant paths in parallel (any one being up keeps the service up), the combined availability is:

$$A_N = 1-(1-a)^N$$

The table below also tracks typical RTO (recovery time objective: how long it takes to restore service once a failure has actually started) at each tier, since that's the other half of the reliability story alongside the downtime-budget math above.

Worked example

Take a building block with $a=0.99$ availability (roughly what a single instance behind basic health checks achieves once you count deploys, patching, and occasional crashes).

$$\begin{aligned} a=0.99,\ N=2:&\quad A_2 = 1-(1-0.99)^2 = 1-(0.01)^2 = 1-0.0001 = 0.9999 \\ a=0.99,\ N=3:&\quad A_3 = 1-(1-0.99)^3 = 1-(0.01)^3 = 1-0.000001 = 0.999999 \end{aligned}$$

Two things fall out of this. First, going from N=1 to N=2 (doubling the redundant footprint, roughly a linear cost step) already buys four nines if the two paths fail independently. Second, N=3 would in theory already clear six nines, far past the five-nines target. So the theoretical redundancy math says five nines should be cheap. It isn't, in practice, because real "independent" replicas usually share a control plane, a DNS provider, a CI/CD pipeline, or a cloud region's power and networking. Those shared dependencies correlate the failures the formula assumes are independent, which is exactly why real five-nines work is dominated by eliminating correlated failure modes (multi-provider network paths, decoupled deploy pipelines, separate blast-radius accounts) rather than by adding a third copy of the same stack.

Trade-offs and pitfalls

The most common wrong turn is buying redundancy (more servers, a second region) without addressing the shared control plane, DNS, or deploy pipeline underneath it. That produces "paper nines": the architecture diagram shows N=2 or N=3, but a single bad deploy or DNS outage still takes the whole thing down, because the redundant paths were never actually independent. A senior answer calls this out explicitly rather than treating "add a region" as sufficient. It's also worth naming that the cost of the top tier isn't only capital: it includes the ongoing operational cost of proving independence through chaos testing and drills, which is recurring, not one-time, and it includes the org cost of tighter RTOs (faster on-call response, more mature runbooks). Finally, most businesses don't need five nines end-to-end; the efficient move is usually to isolate the narrow set of truly critical paths and hold those to five nines while leaving the rest at four, rather than paying the structural cost everywhere.

Direct answer
Difficult feedback to a mentee works best delivered privately, tied to a specific, observed behavior and its concrete impact, not to the person's character, and followed up on to confirm the message landed and something changed. The delivery mechanics matter less than getting three things right: timing (soon after the behavior, not saved up), specificity (a real example, not a vague pattern), and follow-through (checking back in, not treating the conversation itself as the fix).

Structured elaboration

Before the conversation

• Get the facts straight: what exactly happened, what was the impact, and is this a one-off or a pattern. Vague feedback ("you need to be more careful") is unusable; a mentee can't act on a mood, only on a specific instance.
• Decide the stakes. Not all critical feedback carries the same weight:
  • A routine performance gap (missed a deadline, sloppy code style) can wait for the next scheduled 1:1.
  • An ethical or safety concern (something in the person's work poses real risk if it ships) changes the calculus: it needs to happen immediately, privately, and is often paired with a concrete containment step (pause the change, get a second reviewer), not just a conversation.
• Decide the medium: a private 1:1, not written feedback and not in front of the team, unless the finding also needs to be logged for safety or compliance reasons.

Delivering it

• Lead with the specific behavior and its impact, not a label: "this change would have introduced X" is usable; "this was careless" is not.
• Ask before you assert. The mentee may know something you don't (a constraint you weren't aware of); asking "walk me through the reasoning" often surfaces that before you've over-committed to a judgment.
• Separate the person from the work. The message is "this output has a problem," not "you are the problem."

When the power dynamic is reversed

Feedback isn't always flowing to someone junior. Giving critical feedback to a mentee who is more senior, more tenured, or simply more confident than you requires the same content but a different frame: lead with genuine respect for their experience, be more explicit that you're not questioning their general competence, and expect (and plan for) more pushback. Defensiveness here is a normal reaction to a status threat, not necessarily a sign the feedback was wrong; the skill is staying anchored to the specific evidence instead of either escalating or backing down.

After the conversation

• Confirm shared understanding before ending: ask them to restate what they heard.
• Agree on a concrete next step and a checkpoint to revisit it, not just "let's see how it goes."
• Follow up. Feedback that isn't revisited quietly signals it wasn't actually important.

Worked example

Situation

During a code review, I found a race condition in an interrupt service routine (an ISR, the block of code that runs automatically when a hardware event interrupts normal execution) a mentee had written: a shared buffer was being written from the ISR without disabling interrupts around the critical section (the stretch of code that touches shared data and must not be interrupted mid-update), so a preemption (the interrupt firing and pausing the main code at an unpredictable moment) at the wrong moment could corrupt data intermittently and unpredictably.

Why this wasn't routine feedback

This wasn't a style nitpick. Left unaddressed it was a latent, hard-to-reproduce bug that could surface in the field. That pushed it from "note it for next time" to "we talk today, and the change doesn't merge until it's fixed."

The conversation

I asked the mentee to walk me through what happens if the interrupt fires mid-write, rather than telling them the bug outright. They found the failure mode themselves partway through the explanation, so the fix landed as their own understanding rather than my correction. We then talked through the general pattern (anything touching state shared between an ISR and main-line code needs an explicit critical section) so it would generalize past this one bug.

Follow-through

I asked them to check two other places in the codebase where similar shared state existed, as a way to prove the concept had stuck rather than just fixing the one instance. Both had the same latent issue.

Result

The immediate bug was fixed before merge, and the mentee started flagging similar patterns unprompted in their own future changes, which was the real signal the feedback had generalized rather than just been complied with once.

Trade-offs & pitfalls

• The feedback sandwich dilutes the message. Padding critical feedback between two compliments is a common junior instinct; it often causes the actual point to get lost. Genuine positive feedback is worth giving, but on its own merits, not as camouflage for the critical part.
• Waiting to "collect examples" delays too long. A senior mentor gives feedback close to the event; batching several issues into one big conversation later makes it feel like an ambush and makes each point harder to act on.
• Not distinguishing skill gap from something more serious. A performance gap and an ethical or safety issue call for different urgency and different documentation; treating a safety issue as routine coaching is itself a failure mode worth naming.
• Confusing "they got defensive" with "I was wrong." Especially with a more senior or tenured mentee, defensiveness is a predictable reaction to a status threat. A junior mentor backs off; a senior one stays anchored to the specific evidence while still leaving room for the other person to be right about something they missed.

Direct answer

For financial and cart-like data, a cache accelerates reads and coordinates multi-key operations, but the datastore remains the arbiter of correctness; use the datastore's own transaction primitives (or a caching layer's atomic scripting, like Lua) for anything touching money, and reserve conflict-tolerant merges for data where losing a small amount of precision is acceptable (like a shopping cart).

Structured elaboration

• Atomic multi-key updates: transferring a balance between two accounts cached in Redis needs both keys to change together or not at all; Redis transactions (MULTI/EXEC) provide some atomicity guarantees but do not support rollback on a failed condition mid-transaction the way a database transaction does, so a Lua script (which runs atomically and can implement conditional logic) is usually the safer primitive for a check-then-update-both-keys operation.
• Distributed locks as a fallback: where a Lua script is not expressive enough for the operation, a short-lived distributed lock around the specific multi-key operation serializes concurrent attempts, at the cost of added latency and a lock-failure mode to handle.
• Financial-balance read-modify-write: the safest pattern treats the cache as an accelerator, not the ledger; the database performs the actual balance update within its own atomic/transactional guarantees, and the cache is updated (or simply invalidated) afterward, never the other way around.
• Multi-device shopping-cart sync with conflict resolution: unlike a financial balance, a cart update from two devices (add item A on phone, add item B on laptop, both offline briefly) can often be safely MERGED (union of both additions) rather than requiring one to "win"; this is a case where accepting a specific, well-defined conflict-resolution policy (e.g., merge additions, last-write-wins for removals) is both acceptable and necessary, since strict serialization is not achievable for genuinely offline, multi-device edits.
• The role of the database as source of truth: in every one of these cases, the cache's job is to make reads fast and to coordinate the WRITE PATH's mechanics; it should never be the only place a financial fact or an inventory commitment is recorded.

Worked example

A balance transfer between two accounts, both cached in Redis: a Lua script reads both balances, verifies the source account has sufficient funds, and atomically decrements the source and increments the destination within one script execution (Redis guarantees no other command interleaves with a running script), returning success or failure; the database performs the equivalent transactional update as the actual system of record, with the cache values kept in sync via the same write path, never diverging into being their own independent ledger.

Trade-offs and pitfalls

Treating the cache as the ledger (no reconciliation with a durable, transactional datastore) risks permanent, unrecoverable data loss on a cache failure for financial data, which is categorically unacceptable; always keep a durable, transactional source of truth underneath. Applying a cart-style "merge conflicts" policy to financial data (rather than strict correctness) would silently produce wrong balances; match the conflict-resolution strategy to how forgiving the data actually is of a merge.