Storage: SQL, NoSQL, Indexes, Sharding
In this lesson we learn how to choose where an app keeps its data. A database (the organized place where software stores information, like a giant filing cabinet) is the heart of the system. We pick it based on access patterns (how data is actually read and written), on consistency (how important it
System Design (planning how to build big software that serves many people) is like planning a city: roads, storage, traffic lights, and maintenance crews, so the city keeps working well even during the busiest rush hour.
- Storage modeling
- The core skill of this lesson: choosing where to store data (a database) based on how it is actually read and written (access patterns), on consistency, on indexes (a "table of contents" that speeds up search), and on sharding (splitting the data into several parts when it grows too big).
- Trade-off
- A conscious choice that has both a gain and a cost — just like picking a route: the fast road costs a toll, the free one takes longer. In an interview you explain to the interviewer the gain and the cost of each choice.
- Operational metric
- A number that shows whether the decision really works once the system is live and serving real users (production). For example: latency (how long a response takes), error rate (the share of requests that fail), queue lag (how many tasks are waiting in line), and cache hit ratio (how often we found a ready-made answer). Like the gauges on a car dashboard — they tell you if everything is fine.
