# 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? ```hint Anchor the schema Start with the two highest-volume queries and derive keys and relationships from them. ``` ```hint Name the race Show one interleaving that would violate an invariant before choosing a concurrency mechanism. ``` ### What a Strong Answer Covers - A schema justified from access patterns rather than from entity names alone. - Index choices that include write amplification, selectivity, and ordering trade-offs. - A precise CAP discussion tied to a partitioned operation, not a blanket label. - A concurrency plan covering transactions, optimistic or pessimistic control, and retries. ### 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?