Architecture Under Load

Don’t scale before you run into a scale problem.
Solutions to scaling bottlenecks introduce complexity, abstraction, and indirection.
Get metrics: memory, CPU, network I/O, disk I/O.
What gets measured gets managed. Get some monitoring up.
First part where you need to scale: database.
High level: don’t make the web stack do more work than you’d need. Cache at different levels.
Hosting topology: the domain should not point to a web server, it should point to a load balancer. When you have an ELB, you can horizontally scale you application by bringing up new web servers.
Cache database queries, and there are tools that ingest those logs.
Database indexes.
Session data: store it in a different, in-memory caching tool like Redis or memcached.
Run computations offline via jobs. And split those jobs. Ex: you can generate some HTML files for your entire web app and serve it to users as static files. (Ex: static site generators).
HTML fragment caching.
HTTP caching with the headers.
CDN.

Every Message Counts: Kafka as a Foundation for Highly Reliable Logging at AirBnb

Started off with Rails → Kafka → Hive. Then expanded.
Now, other teams (such as search results) wanted to use this service.
Reliable logging:
- Schemas as a contract.
- Events are delivered reliably/can recover if restarted.
- Events are available in real-time.
- Schemas and data are discoverable.

A conceptual model of the domain that incorporates both behavior and data. A formal representation of a knowledge domain with concepts, roles, datatypes, individuals, and rules.