Scalability Golden Rules

Clones

It is a form of horizontal scaling.

• Public servers are hidden behind a load balancer, evenly distributing load (requests from your users) onto your group/cluster of application servers.

• Every server contains the same codebase and does not store user-related data, like sessions or profile pictures, on a local disc or memory.

• Sessions need to be stateless. If sessions are stateful, they must be stored on a centralized data store accessible to all your application servers. It can be an external database or persistent cache, like Redis.

• Use tools to gradually deploy code to each server (blue-green deployment, canary deployment, etc.)

Database

• Primary-secondary replication (only requires vertical scaling considerations on primary)

  • Write to primary

  • Read from secondary

• Denormalization, SQL tuning, and partitioning (sharding, etc.).

• If your data has a known structure, stick to a SQL database (PostgreSQL/MySQL). Mainly all applications bear some structure to the intrinsic data. Even SQL databases can store queryable unstructured data. Alternatively, use proficient NoSQL data (MongoDB/CouchDB).

• Avoid joins and try to stay denormalized to avoid joins. They slow down distributed systems.

Cache

• Cache here usually means in-memory caches (Memcached/Redis, Redis includes extra database features like persistence and the built-in data structures like lists and sets).

• Never do file-based caching. It makes cloning and auto-scaling of your servers challenging.

• A cache is a simple key-value store that should reside as a buffering layer between your application and your data storage. Whenever your application has to read data, it should first try to retrieve the data from your cache. Redis can do hundreds of thousands of reading operations (READ) per second when hosted on a standard server.

• Two data caching patterns:

  • Cached Database Queries: Whenever you query your database, you store the result dataset in the cache. A hashed version of your query is the cache key.

  • Cached Objects: See your data as an object like you already do in your code (classes, instances, etc.). Let your class assemble a dataset from your database and then store the complete instance of the class or the assembled dataset in the cache. Some ideas of objects to cache: user sessions (never use the database!), fully rendered blog articles, activity streams, account relationships, etc.

Asynchronism

• Async #1: Doing the time-consuming work in advance and serving the finished work with a low request time. It is to turn dynamic content into static content. Pages of a website, maybe built with a massive framework or CMS, are pre-rendered and locally stored as static HTML files on every change. Often these computing tasks are done regularly.

• Async #2: Handle tasks asynchronously as a background process. RabbitMQ is one of many systems that help to implement async processing. You could also use ActiveMQ or a simple Redis list. The basic idea is to have a queue of tasks or jobs that a worker can process.