Top 30 Consistency Interview Questions and Answers

30 questions. Pick an answer, or open “Show the answer” to read it.

Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.

1. Question 1 of 30

   A product manager insists on a custom component that violates the design system. Which response best articulates the long-term debt cost?

   • aRefuse to ship the feature until the team agrees to a full immediate refactor using the standard component
   • bPresent user churn data showing inconsistency hurts NPS but leave the fix schedule open-ended
   • cEstimate the extra frontend hours for the custom build and warn that inconsistency may confuse users
   • dModel the 3-5x post-launch refactor multiplier, attach a risk matrix, and propose a time-boxed experiment with hard deprecation
   Show the answer

   Answer: d · Model the 3-5x post-launch refactor multiplier, attach a risk matrix, and propose a time-boxed experiment with hard deprecation

   Modeling the 3-5x refactor multiplier, attaching a risk matrix, and proposing a time-boxed experiment reflects the card's four-layer framework for stakeholder translation. Distractor A is tempting because it enforces the design system, but the card flags demanding an immediate full refactor without acknowledging delivery pressure as a red flag.

   Read the full bite: How do you model and articulate long-term design debt cost to stakeholders?

2. Question 2 of 30

   A social app adds a like_count column directly on the posts table instead of counting rows in a likes table on every read. According to the card, what new problem does this denormalization introduce?

   • aThe count can drift out of sync if updates aren't handled atomically, requiring periodic reconciliation
   • bReads become slower because the column must still be computed with a join
   • cIt removes the need for any consistency handling since counts are now precomputed once
   • dIt only works if the underlying database doesn't support ACID transactions
   Show the answer

   Answer: a · The count can drift out of sync if updates aren't handled atomically, requiring periodic reconciliation

   The card's example warns that a missed update or race condition can leave the count wrong, requiring periodic reconciliation, that is the core cost of denormalizing. The tempting wrong answer has it backwards: the point of adding the column is that reads become a fast single column fetch, not a join.

   Read the full bite: When to intentionally denormalize a schema

3. Question 3 of 30

   Why do many teams map semantic t-shirt-size spacing tokens onto an underlying numeric base-unit grid rather than choosing only one approach?

   • aIt lets designers use arbitrary values outside the scale
   • bIt eliminates the need to define any concrete pixel values at all
   • cIt gives readable, intent-based names backed by predictable, grid-aligned math
   • dIt guarantees the layout works without responsive breakpoints
   Show the answer

   Answer: c · It gives readable, intent-based names backed by predictable, grid-aligned math

   Combining them keeps the clarity of named intent while the numeric base ensures consistent, composable alignment. The named tokens still resolve to concrete values, and a scale constrains rather than permits arbitrary spacing.

   Read the full bite: Choosing a spacing scale for a design system

4. Question 4 of 30

   Two clients concurrently update the same object in a strongly consistent object store. What is the realistic outcome?

   • aBoth versions are kept and reconciled automatically on read
   • bLast writer wins and one update is silently lost without coordination
   • cThe store merges both writes into a single combined object
   • dThe second write blocks until the first releases a lock
   Show the answer

   Answer: b · Last writer wins and one update is silently lost without coordination

   Object stores replace whole objects with no built-in locking, so concurrent PUTs are last-writer-wins and an update is lost unless you use conditional writes. There is no automatic merge, lock, or reconciliation.

   Read the full bite: Object store vs NFS consistency models

5. Question 5 of 30

   What is the fundamental trade-off that eventual consistency embraces in distributed systems?

   • aIt guarantees that all read operations will always reflect the most recent write, potentially delaying system availability.
   • bIt ensures strict chronological ordering of all operations at the cost of increased network overhead.
   • cIt sacrifices data durability to achieve faster write speeds across all nodes.
   • dIt prioritizes continuous system uptime and responsiveness over immediate, global data consistency.
   Show the answer

   Answer: d · It prioritizes continuous system uptime and responsiveness over immediate, global data consistency.

   Eventual consistency's core principle is to prioritize high availability and system responsiveness, allowing temporary data inconsistencies across replicas. Option A describes a characteristic of strong consistency, where reads are guaranteed to be up-to-date, which is the opposite of eventual consistency's approach during the replication window.

   Read the full bite: Eventual Consistency: Availability Over Immediacy

6. Question 6 of 30

   When is choosing eventual consistency over strong consistency the better engineering decision?

   • aWhen the application cannot tolerate any replication between nodes
   • bWhen you want reads to consume more provisioned capacity for safety
   • cWhen the read must never be even momentarily stale, such as an account balance check
   • dWhen brief staleness is harmless and you want lower latency, cost, and higher availability
   Show the answer

   Answer: d · When brief staleness is harmless and you want lower latency, cost, and higher availability

   Eventual consistency trades momentary staleness for speed, lower cost, and availability, ideal for tolerant data like feed counts. Balance checks need strong consistency, making the first option wrong.

   Read the full bite: Strong versus eventual consistency in NoSQL

7. Question 7 of 30

   According to the CAP theorem, what is the actual decision a distributed system faces, and when does it apply?

   • aYou permanently choose any two of the three properties regardless of network state
   • bYou can always have all three if your hardware is reliable enough
   • cPartition tolerance is optional and usually dropped first
   • dDuring a network partition you must trade off between consistency and availability
   Show the answer

   Answer: d · During a network partition you must trade off between consistency and availability

   Because partitions are inevitable, the binding choice arises only during a partition: stay consistent and reject requests, or stay available and serve stale data. The pick-two framing and dropping partition tolerance are common misreadings.

   Read the full bite: What is the CAP theorem?

8. Question 8 of 30

   A candidate proposes a global multi-region database with low-latency local writes everywhere and full strong global consistency at minimal cost. What is the flaw?

   • aAdding regions reduces cost, so the cost claim is the only error
   • bMulti-region databases cannot accept writes in more than one region
   • cReplication between regions is always instantaneous, so consistency is never an issue
   • dStrong global consistency requires cross-region coordination, which conflicts with the low local write latency goal
   Show the answer

   Answer: d · Strong global consistency requires cross-region coordination, which conflicts with the low local write latency goal

   Strong global consistency forces synchronous cross-region coordination, raising write latency and cost. You cannot get low local latency, strong global consistency, and low cost at once, which is the core tradeoff.

   Read the full bite: Design a global low-latency database

9. Question 9 of 30

   Which feature is the clearest case where eventual consistency would be unacceptable and strong consistency is required?

   • aDisplaying the number of views on a video
   • bRendering a social media activity feed
   • cDecrementing the remaining stock of a limited-edition item at checkout
   • dShowing a user's follower count
   Show the answer

   Answer: c · Decrementing the remaining stock of a limited-edition item at checkout

   Limited inventory must be strongly consistent or two buyers could purchase the same last unit. View counts, follower counts, and feeds tolerate brief staleness without causing real harm.

   Read the full bite: What are eventual consistency and the BASE model?

10. Question 10 of 30

    According to the CAP theorem, when is the consistency-versus-availability tradeoff actually forced on a distributed database?

    • aNever, because systems like Spanner achieve all three permanently
    • bOnly when the database is single-node and cannot partition
    • cOnly during a network partition, when the system must choose consistency or availability
    • dAt all times, since every system must permanently give up one of the three properties
    Show the answer

    Answer: c · Only during a network partition, when the system must choose consistency or availability

    Partition tolerance is mandatory, so the real choice between consistency and availability only arises during a partition. Outside a partition a system can offer both, and Spanner does not beat CAP.

    Read the full bite: CAP theorem and real database tradeoffs

11. Question 11 of 30

    What guarantee does a Saga provide that distinguishes it from a true multi-document ACID transaction?

    • aIt provides full isolation so intermediate states are never visible
    • bIt provides atomicity via compensating transactions but not isolation, so partial states can be observed
    • cIt guarantees instant strong consistency across all services
    • dIt locks all participants until every step commits
    Show the answer

    Answer: b · It provides atomicity via compensating transactions but not isolation, so partial states can be observed

    A Saga achieves all-or-nothing through compensations but cannot isolate intermediate steps, so partial results are visible. Locking all participants describes two-phase commit, and Sagas yield eventual, not instant strong, consistency.

    Read the full bite: How do you keep consistency without multi-document transactions?

12. Question 12 of 30

    A growing codebase has many slightly different buttons across teams. Which design system benefit most directly addresses this?

    • aSmaller JavaScript bundles
    • bFaster initial project setup
    • cAutomatic backend API generation
    • dA single source of truth for reusable components that eliminates UI drift
    Show the answer

    Answer: d · A single source of truth for reusable components that eliminates UI drift

    A shared, single source of truth for components stops each team from reinventing primitives, eliminating the drift. Bundle size and backend concerns are unrelated to the consistency problem described.

    Read the full bite: Purpose of a design system for developers

13. Question 13 of 30

    In a tiered entitlement cache, how should temporary grants be modeled to avoid degrading cache hit rates?

    • aStore them in the local in-process cache with the same long TTL as static plan features
    • bEnforce strong consistency across regions for temporary grants while using eventual consistency for static features
    • cQuery the primary database directly for every temporary grant check to avoid cache churn
    • dAppend them to an event-sourced log and cache with a TTL matching their explicit expiration
    Show the answer

    Answer: d · Append them to an event-sourced log and cache with a TTL matching their explicit expiration

    Temporary grants are high-churn, time-bound state that pollutes the cache if handled like static features; event-sourced append-only logs with precise TTLs keep them off the hot path without overwhelming the database. Querying the primary store directly for every check would recreate the exact bottleneck a multi-tier cache is designed to prevent.

    Read the full bite: Design a highly available entitlements service with caching

14. Question 14 of 30

    Why should a UI consistency score expose its underlying signal breakdown rather than just a single number?

    • aThe breakdown tells teams which specific signal to fix, making the score actionable
    • bA single number is mathematically impossible to compute
    • cBreakdowns are required by Semantic Versioning
    • dSingle scores cannot be tracked over time
    Show the answer

    Answer: a · The breakdown tells teams which specific signal to fix, making the score actionable

    A breakdown turns the score into guidance, showing exactly which signal (tokens, overrides, components) to improve. A single number is computable and trackable, but opaque and not actionable on its own.

    Read the full bite: Designing a UI consistency score

15. Question 15 of 30

    A banking ledger refuses writes on a node it cannot safely coordinate during a network partition. How does this position it on the CAP trade-off?

    • aIt is an AP system favoring availability over consistency
    • bIt proves you can have all three of C, A, and P at once
    • cIt avoids the CAP trade-off entirely by being a single server
    • dIt is a CP system sacrificing availability to preserve consistency during the partition
    Show the answer

    Answer: d · It is a CP system sacrificing availability to preserve consistency during the partition

    Refusing writes to avoid divergence trades availability for consistency, the defining behavior of a CP system under partition. Serving despite staleness would be AP, and CAP's trade-off cannot be escaped in a distributed system.

    Read the full bite: Apply the CAP theorem to a real system

16. Question 16 of 30

    A team moves from leader-follower to multi-leader replication across two regions. Which new problem must they now explicitly design for?

    • aThe leader becoming a single point of failure
    • bConcurrent conflicting writes to the same record
    • cRead replicas becoming stale
    • dLoss of all transaction support
    Show the answer

    Answer: b · Concurrent conflicting writes to the same record

    Multiple leaders accepting writes asynchronously means two regions can edit the same record concurrently, requiring conflict resolution. Stale read replicas also exist in plain leader-follower, so that is not the new problem multi-leader introduces.

    Read the full bite: Leader-follower vs multi-leader replication

17. Question 17 of 30

    Which feature is the WEAKEST candidate for eventual consistency and most likely needs strong consistency instead?

    • aUpdating a trending-topics list
    • bDecrementing limited inventory at checkout
    • cShowing a user's follower number
    • dDisplaying a post's like count
    Show the answer

    Answer: b · Decrementing limited inventory at checkout

    Selling the same last unit twice due to a stale read causes real harm, so inventory decrement at checkout needs strong consistency. Like counts, follower numbers, and trending lists tolerate brief staleness without consequence.

    Read the full bite: What is eventual consistency?

18. Question 18 of 30

    Why might a team deliberately keep most transactions at Read Committed instead of Serializable?

    • aIt allows higher concurrency by tolerating some anomalies, while Serializable adds locking/retries
    • bSerializable cannot be used with indexes
    • cRead Committed prevents all concurrency anomalies
    • dRead Committed disables transactions entirely
    Show the answer

    Answer: a · It allows higher concurrency by tolerating some anomalies, while Serializable adds locking/retries

    Read Committed permits non-repeatable and phantom reads but allows more concurrency, while Serializable's stronger guarantees cost locking or transaction retries. Read Committed does not prevent all anomalies or disable transactions.

    Read the full bite: Transaction isolation levels and their tradeoffs

19. Question 19 of 30

    In a distributed system with N nodes, what condition must the write quorum (W) and read quorum (R) satisfy to guarantee a read operation always sees the most recent write?

    • aW >= N/2 + 1
    • bW + R = N
    • cW + R > N
    • dW and R must both be equal to N
    Show the answer

    Answer: c · W + R > N

    The rule W + R > N ensures that any set of nodes forming a read quorum will always overlap with any set of nodes forming a write quorum, guaranteeing that the reader will encounter at least one node that received the latest write. Option B (W + R = N) does not guarantee this overlap, as the write and read sets could be disjoint.

    Read the full bite: Quorum: How Distributed Systems Agree Without Unanimity

20. Question 20 of 30

    After a user updates their settings, they reload and see the old values. What is the least disruptive fix that preserves read scaling?

    • aRoute that user's reads to the primary briefly after their write
    • bConvert all read replicas to synchronous replication
    • cAdd a client-side cache to store the user's latest values
    • dDisable read replicas and serve everything from the primary
    Show the answer

    Answer: a · Route that user's reads to the primary briefly after their write

    Pinning the user to the primary for a short window gives read-your-writes consistency while keeping replicas for everyone else. Synchronous replication everywhere defeats the scaling purpose.

    Read the full bite: Replica lag and read-your-writes consistency

21. Question 21 of 30

    In the cache-aside pattern, what must the application do on a write to avoid serving stale data?

    • aDisable the TTL so cached entries never expire
    • bNothing; the cache automatically detects the database change
    • cWrite only to the cache and let it flush to the database later
    • dUpdate or invalidate the corresponding cache key after writing to the database
    Show the answer

    Answer: d · Update or invalidate the corresponding cache key after writing to the database

    Cache-aside puts invalidation in the application's hands, so after a write it must update or delete the affected key. The cache does not observe database changes on its own.

    Read the full bite: Cache-aside pattern with Redis and RDS

22. Question 22 of 30

    In a large design system, which situation most favors building a specific composite component over relying on generic primitives?

    • aAny case where you want to minimize the public API surface
    • bA common, stable pattern repeated identically across many screens
    • cA layout pattern that varies widely and is still evolving
    • dA one-off experimental screen built by a single team
    Show the answer

    Answer: b · A common, stable pattern repeated identically across many screens

    Composites pay off when a pattern is frequent and stable, because they centralize consistency and accessibility. Evolving or one-off layouts favor flexible primitives, and composites actually grow the API surface rather than shrink it.

    Read the full bite: Composite components versus layout primitives

23. Question 23 of 30

    An architect promises an active-active multi-region store with strong consistency, the lowest possible write latency, and zero data loss on failover. What is the core problem with this claim?

    • aOnly NoSQL databases can do this, not SQL
    • bPACELC says even without a partition you must trade latency against consistency
    • cIt is achievable with enough replicas
    • dIt works as long as clocks are perfectly synchronized
    Show the answer

    Answer: b · PACELC says even without a partition you must trade latency against consistency

    PACELC and CAP establish that strong cross-region consistency forces higher write latency, and partitions force a consistency-versus-availability choice. No amount of replicas or clock sync removes that fundamental trade-off.

    Read the full bite: Replication and consistency for active-active regions?

24. Question 24 of 30

    A key advantage of cache-aside over write-through is that it:

    • aGuarantees the cache and database are always perfectly consistent
    • bKeeps the cache off the write path, so reads survive a cache outage by falling back to the database
    • cCaches the entire dataset proactively before any request arrives
    • dEliminates the need for the application to manage cache keys
    Show the answer

    Answer: b · Keeps the cache off the write path, so reads survive a cache outage by falling back to the database

    Cache-aside caches lazily and isn't on the write path, so a cache outage degrades gracefully to database reads. It does not guarantee perfect consistency, and the application still manages keys and invalidation.

    Read the full bite: Cache-aside pattern pros and cons

25. Question 25 of 30

    A service must guarantee that any payment it confirms survives a primary crash. Which replication choice fits, and what is its main cost?

    • aSynchronous replication; cost is unbounded replication lag
    • bSynchronous replication; cost is higher commit latency and stalls if a replica is down
    • cAsynchronous replication; cost is possible data loss on failover
    • dAsynchronous replication; cost is higher write latency
    Show the answer

    Answer: b · Synchronous replication; cost is higher commit latency and stalls if a replica is down

    Synchronous replication waits for a replica acknowledgment, so confirmed writes survive primary failure, but commits pay round-trip latency and can stall when the replica is unavailable. Async would risk losing the most recent confirmed payment.

    Read the full bite: Synchronous vs asynchronous replication trade-offs

26. Question 26 of 30

    You store a precomputed review_count on each product row to speed up reads. What is the primary cost of this denormalization?

    • aThe product table can no longer be indexed
    • bEvery review write must also update and keep the count consistent
    • cReads now require an extra join to the reviews table
    • dQuery latency increases because of the redundant column
    Show the answer

    Answer: b · Every review write must also update and keep the count consistent

    Denormalization trades read speed for write complexity and consistency risk: the duplicated count must be maintained on every review change or it drifts from the source data. Reads get faster, not slower, and the table remains fully indexable.

    Read the full bite: Denormalization: trading write cost for read speed

27. Question 27 of 30

    Which choice best balances flexibility with system consistency when designing a reusable Card component's API?

    • aAdd one boolean prop for every possible visual tweak
    • bHard-code all content and layout so nothing can vary
    • cExpose a style prop so consumers can override any visual aspect
    • dAccept content via slots and offer constrained enum variants tied to tokens
    Show the answer

    Answer: d · Accept content via slots and offer constrained enum variants tied to tokens

    Composition handles content flexibly while enum variants mapped to tokens keep visuals on-brand. A free-form style prop (option C) lets consumers break consistency, the exact failure mode design systems exist to prevent.

    Read the full bite: Designing a Card component's configurable API

28. Question 28 of 30

    After an operator crashes between provisioning an external service and writing .status, what is the most robust recovery on restart?

    • aRe-observe the real external state each reconcile and set status from that, idempotently
    • bAssume the external action failed and recreate the service unconditionally
    • cTrust the last cached status value to avoid redundant external calls
    • dSkip status updates until the next user-triggered change
    Show the answer

    Answer: a · Re-observe the real external state each reconcile and set status from that, idempotently

    Because the action and status write are not atomic, the only reliable source is the external system itself; reconcile must re-observe and reconcile idempotently. Trusting cached status risks reporting stale or wrong state, and unconditional recreation can duplicate resources.

    Read the full bite: Keeping operator .status accurate under failures

29. Question 29 of 30

    Which design choice best explains why a micro-commitment during onboarding increases long-term feature adoption?

    • aIt creates a record of user preferences for future personalization algorithms
    • bIt increases the perceived sunk cost of time already spent in the onboarding flow
    • cIt establishes an identity the user later acts to confirm without additional persuasion
    • dIt triggers a dopamine reward when the user sees their choice reflected in the UI
    Show the answer

    Answer: c · It establishes an identity the user later acts to confirm without additional persuasion

    The card describes the mechanism as self-perception and cognitive dissonance: a small voluntary choice lets users internalize an identity they then seek to confirm. Option B is tempting because sunk cost is a real bias, but it is a separate mechanism from identity-driven consistency.

    Read the full bite: Commitment and Consistency: The Identity Ratchet

30. Question 30 of 30

    For an application where immediate data consistency across all replicas is non-negotiable and data loss is unacceptable, which replication strategy is most appropriate?

    • aAsynchronous replication, to ensure high availability and low write latency.
    • bSynchronous replication, despite potential increases in write latency.
    • cRead-replica scaling, to distribute the read load efficiently.
    • dEventual consistency models, to optimize for read performance.
    Show the answer

    Answer: b · Synchronous replication, despite potential increases in write latency.

    Synchronous replication guarantees that a write is not considered complete until all replicas confirm the change, ensuring immediate consistency and preventing data loss, though at the cost of higher write latency. Asynchronous replication prioritizes low write latency and availability but allows for temporary inconsistencies and potential data loss.

    Read the full bite: Synchronous vs. Asynchronous Replication: A Trade-off