The first chapter basically giving the high level overview of how do you architect data driven applications. Your primary database is not just a single server. It's probably thousands of servers doing sharding, some kind of distributed system. But the very basic architecture is: you have application servers connecting to your primary database, usually something like MySQL or Postgres, for your OLTP workload. Then often there's other data systems: Elasticsearch or Algolia for full text search, data ingestion message queue systems for asynchronous tasks, and dedicated Redis or Memcached caches to help reduce load and keep things snappy.

One of the reasons why the relational model became so popular is because SQL is not imperative, it's declarative. When you write a SQL query, you're declaring "this is what I want." You let the database choose how it's going to fulfill that. There's a lot of opportunity for optimization. In older style databases, querying was essentially imperative, writing pseudo code to describe your query. This requires you to optimize your queries yourself. SQL is powerful because the database is responsible for knowing the structure of your data and the indexes. Query optimizers take a query string, break it up, and go through a big decision making process: should I do a table scan or use the B tree index?

P50 means half of your queries executed faster than that value. P99 and P99.9 are useful metrics for monitoring performance, but you got to be careful with them. If your P99.9 was 30 milliseconds over a minute with one million queries, that's ignoring 1,000 queries that could be going way slower, like giant full table scans taking 10 seconds each. Even though these metrics are useful, they don't tell the full story. You actually need to look at every single query, not just your percentile values.

Data locality is an interesting tradeoff. In a document database like MongoDB, you could put everything (name, education, job descriptions) in one document. One database request, one disk I/O, you get most of what you need. In a relational database, the user row, employment rows, education rows are scattered in different tables. This could end up being many different separate requests to disk. However, the relational model reduces redundancy. For example, the string "Microsoft" doesn't have to be stored 100,000 times in everybody's profile; you store it once in a company table. The concept of enforcing your schema when you write data (Schema-on-write) is a big advantage of relational databases.

Sometimes it is worth using a new database if you have a particular kind of problem. Graph databases can specify graph traversals in four lines, where SQL might take 20 lines of recursive CTEs. Pretty much any data set can be modeled with relational schemas, but you might be suffering on the performance side. Sometimes it makes sense to choose an additional tool like ClickHouse for time-series heavy data or Elasticsearch for text search. It's about choosing the tools that pair well together and finding the right tool for the job.