2. Design the schema for a system with Books and Authors, where a book can have multiple authors and an author can write multiple books. (Looking for the Book, Author, and BookAuthor join table.) When deciding what to index, what columns would you choose and why? (i.e. primary keys, foreign keys, and columns you frequently filter by, e.g. author name.)

3. Indexing Trade-offs: What are the downsides of adding indexes? (Looking for: writes become slower because every index must be updated on insert/update, and indexes consume disk and memory.)

4. Concurrency & Lost Updates: Describe a concrete scenario that leads to a lost update. How could you reduce the probability of a lost update occurring? Suppose Richard and Anna both edit the same phone number at the same time — one is adding an international dialing code while the other is changing the number entirely. How would you detect that one person's change is about to overwrite the other's, reject the second write, and inform whoever submitted second? (Looking for optimistic locking / version numbers.)

5. Transactions & ACID: Why do we wrap these multi-table writes in a transaction? Explain in terms of: Not leaving the database in a half-written state (atomicity / rollback), Not reading the database in a half-written state (isolation)

6. Relational vs. JSON Storage: What are the trade-offs of storing data as a JSON blob versus normalized relational tables? (Looking for: with JSON you store column names and all the syntactic structure inside the data itself, whereas Postgres stores that schema metadata outside the row; and JSON encourages data duplication because you embed relational data directly instead of referencing it via foreign keys.)

7. Schema Migration Strategy: After creating the new Address table, how do you safely migrate? Walk through backfilling the address table and then removing the backend's references to the old address fields.

8. API Versioning: The API currently returns a single address, but now needs to support multiple addresses. How would you evolve the endpoint without breaking existing clients? (Looking for: either a new endpoint version, or temporarily exposing both address and addresses fields.) How would you coordinate the frontend rollout? (e.g. first upgrade the frontend to read the new addresses field — showing an error telling the user to refresh if it unexpectedly detects multiple addresses — then later upgrade it to fully support multiple addresses.)