Systems can be scaled:<ul><li>Vertically - by increasing the resources of a specific node (more CPU, memory, disk etc.). This is easier to do, but it's limited. You can only add so many CPU cores and memory.</li><li>Horizontally - by adding more nodes of the same kind. This usually requires adding a load balancer in front of your nodes to distribute the load evenly.</li></ul>

Scaling

Joins in relational databases get very slow as the system grows bigger. You should denormalize your data to avoid joins and speed up your queries.Normalized databases are designed to minimize redundancy, while denormalized databases are designed to optimize read time.

Database denormalization

Sharding means splitting your data across multiple nodes. This can be done in different ways:1. Vertical sharding<ul><li>Store tables on different nodes.</li><li>Drawback: If one of these tables gets very large, then you need to re-shard that database.</li></ul>2. Key-based sharding<ul><li>Use part of your data (usually the row ID) to shard it.</li><li>Drawback: The number of nodes is fixed. If you want to add more nodes, then you have to reallocate the data.</li></ul>3. Directory-based sharding<ul><li>Maintain a lookup table for where each data is found.</li><li>Drawback: The lookup table is a single point of failure, that's constantly under load.</li></ul>

Database sharding

Caching systems are usually in-memory key-value databases that provide very fast access to data. They sit between your application and the database.Depending on your use case, you can either cache only the results of the database queries, or cache the entire response objects (such as fully rendered web pages).

Caching

Slow operations should be done asynchronously to avoid making users wait for long periods of time until their requests are processed.Sometimes this can be done in advance, by pre-processing data that you know users will need. For example, a forum might periodically re-render its page of most popular posts and the number of comments.Asynchronous processing usually requires 2 components:<ol><li>A queue that stores tasks, ordered by time and priority</li><li>A&nbsp;system that processes tasks</li></ol>

Asynchronous processing

<ul><li>Bandwidth - Maximum amount of data that can be transferred in a unit of time. Usually expressed in bits per second.</li><li>Throughput - Amount of data that is actually transferred in a unit of time.</li><li>Latency - How long it takes data to go from one end to the other.</li></ul>

Networking metrics

Software Architecture

Key Concepts for System Design

Review your API endpoints and views for:<ul><li>Duplicate queries</li><li>Slow queries</li><li>ORM calls that resolve more queries than you expect</li></ul>

Finding query bottlenecks

<ol><li>Reduce number of queries</li><li>Speed up common queries</li><li>Cache results of heavy queries</li><li>Turn off ATOMIC_REQUESTS -- This settings makes all queries run in a transaction. Read Django docs before changing it to understand the trade-offs.</li><li>Tune database settings</li></ol>

Tips to reduce query bottlenecks

<ul><li>Use select_related() to retrieve Foreign Key relations in the same query.</li><li>Use prefetch_related() for many-to-many and many-to-one relations.</li><li>Re-use query results across the lifetime of the request if you need them in more places.</li></ul>

Reduce number of queries

<ul><li>Add indexes on fields you frequently filter/sort on.</li><li>Analyze query plans generated by common queries and identify bottlenecks.</li><li>Rewrite queries to return smaller results sets when possible.</li><li>Re-model data in a way that allows indexes to work more efficiently.</li><li>As a last resort, use raw SQL when you can't generate an efficient query through the ORM.</li></ul>

database

Scaling

Key Concepts for System Design

Finding query bottlenecks

Speed up query-heavy requests