Katkat
Back

Defend a Project's Schema, Indexes, and Concurrency Model

ByteDanceSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSoftware Engineering Fundamentals

Last updated

Practice defending a database design by connecting schema choices, indexes, consistency behavior, and concurrency controls to concrete access patterns. The solution explains how to reason about CAP trade-offs, lost-update prevention, transaction boundaries, and the operational cost of each index.

Defend a Project's Schema, Indexes, and Concurrency Model

Choose one data-heavy service you have built and defend its data model under a detailed technical review. Explain the schema, why its relationships and field boundaries fit the access patterns, which indexes are justified, what consistency behavior you expect during a network partition, and how concurrent updates avoid lost writes or broken invariants.

Constraints & Assumptions

  • Use one real or clearly labeled hypothetical service throughout the answer.
  • Name at least two concrete read or write access patterns before proposing indexes.
  • Separate database transaction isolation from distributed replica consistency.
  • State the invariant protected by each lock, version check, or transaction boundary.

Clarifying Questions to Ask

  • Which fields or relationships are queried most often, and which writes dominate?
  • May clients tolerate stale reads, and if so, for which operations?
  • Can two requests legitimately update different fields of the same record concurrently?

Hints

Hint 1

Anchor the schema: Start with the two highest-volume queries and derive keys and relationships from them.

Hint 2

Name the race: Show one interleaving that would violate an invariant before choosing a concurrency mechanism.

Follow-up questions

  • How would the design change if the hottest query became a range scan by time?
  • How would you detect an index that costs more in writes than it saves in reads?