Use indexes, migrations, Redis, MongoDB, and data-access patterns responsibly.
Data · schema and storage
Use the strong answer as your reference, explain it aloud in your own words, then choose how soon you want to review it again.
Interview prompt
Strong answer
Data design starts from queries and invariants: constraints in the database protect correctness, indexes are chosen from real WHERE, JOIN and ORDER BY patterns, and every schema change ships as a versioned, reviewable migration. Caching is an optimization layered on top of a correct source of truth, so define what may be stale, for how long, and how entries are invalidated. Pick a document store such as MongoDB only when the access pattern really is aggregate-shaped.
Key points
Interviewer looks for
Talk about trade-offs: what goes in a constraint versus code, why an index can slow writes, how you roll out a column rename with zero downtime, and how a cached value can become wrong.
Java example
1-- V7__add_order_status_index.sql (Flyway)
2CREATE INDEX CONCURRENTLY idx_orders_customer_created
3 ON orders (customer_id, created_at DESC);
4
5@Service
6class ProductCatalog {
7 private final ProductRepository products;
8 ProductCatalog(ProductRepository products) { this.products = products; }
9
10 @Cacheable(cacheNames = "product", key = "#sku", unless = "#result == null")
11 public ProductView find(String sku) {
12 return products.findViewBySku(sku);
13 }
14
15 @CacheEvict(cacheNames = "product", key = "#sku")
16 public void priceChanged(String sku) { }
17}Topic interview questions
These questions are tied to this lesson. Read each question aloud, then compare your explanation with the strong answer.
Strong answer
Flyway applies ordered, versioned SQL scripts that are reviewed, checksummed, and recorded in a history table, so every environment converges to the same schema. ddl-auto=update guesses changes, cannot handle renames or data moves safely, and should not run against production.
Strong answer
Use expand and contract: add the new column, write to both, backfill in batches, switch reads to the new column, deploy, and only then drop the old column in a later release. Each step remains compatible with the version of the application still running.
Strong answer
Read the execution plan, then index the columns used for equality filters first, followed by range or sort columns, matching the query's access path. Check selectivity, consider covering columns, and remember every index adds write and storage cost.
Strong answer
Stale reads after updates, races where an old value is re-cached after eviction, and stampedes when a hot key expires and many requests hit the database at once. Mitigate with explicit eviction on writes, short TTLs, jitter, request coalescing, and treating the database as the source of truth.
Strong answer
When data is naturally read and written as a self-contained aggregate with a flexible shape and few cross-document joins or multi-entity transactions. If the domain relies on relational integrity, ad hoc joins, or reporting, a relational database is usually the safer default.
How well do you know this?
Your review choice is saved locally and synced to your learner profile when signed in.