Awesome Scalability, Availability, and Stability Backend

A curated list of selected readings/case studies to illustrate Scalability, Availability, and Stability patterns in backend design.

What if your backend went slow?

Understand your problems: performance problem (slow for a single user) or scalability problem (fast for a single user but slow under heavy load) from basic.

What if your backend went down?

"Even if you lose all one day, you can build all over again if you retain your calm!" - Thuan Pham, CTO at Uber Technologies Inc.

Contributing

Please take a look at the contribution guidelines first. Contributions are always welcome!

Contents

• Basic
• Scalability
• Availability
• Stability

Basic

• CAP Theorem and the Trade-offs
• Scale up vs Scale out
• Latency vs Throughput: Striving for maximal throughput with acceptable latency
• ACID?
• Architecture Issues: Bottlenecks, Database, CPU, IO
• Immutability

Scalability

• Distributed Caching
  • Write-behind and Write-through
  • Eviction Policies
  • Peer-To-Peer Caching
• Distributed Logging & Tracing
  • Building DistributedLog at Twitter: High-performance replicated log service
  • Distributed tracing at Pinterest with Pintrace
  • Scalable and reliable log ingestion at Pinterest
• Storage
  • In-memory Storage
    • Optimizing Memcached Efficiency at Quora
  • Durable Storage (S3)
    • Reasons for Choosing S3 over HDFS at Databricks
    • S3 in the Data Infrastructure at Airbnb
    • Quantcast File System on Amazon S3
    • Using S3 in Netflix Chukwa
• NoSQL
  • Key-Value Databases (DynamoDB, Voldemort, Manhattan)
    • Scaling Mapbox infrastructure with DynamoDB Streams
    • Manhattan: Twitter’s distributed key-value database
  • Document Databases (Cassandra, Vertica, Sybase IQ)
    • Consistent Hashing in Cassandra
    • When NOT to use Cassandra?
    • Storing Images in Cassandra at Walmart Scale
    • Cassandra at Instagram
    • How Yelp Scaled Ad Analytics with Cassandra
    • How Discord Stores Billions of Messages with Cassandra
  • Graph Databases (MongoDB, CouchDB, Neo4j)
    • eBay: Building Mission-Critical Multi-Data Center Applications with MongoDB
    • MongoDB at Baidu: Multi-Tenant Cluster Storing 200+ Billion Documents across 160 Shards
  • Datastructure Databases (Redis, Hazelcast)
    • How Twitter Uses Redis To Scale
    • Redis in Slack job queue
    • Moving persistent data out of Redis at Github
• RDBMS
  • Why SQL is beating NoSQL, and what this means for the future of data
  • Sharding at Pinterest
  • How Airbnb Partitioned Main Database in Two Weeks
  • Replication is the Key for Scalability & High Availability
  • How Twitch uses PostgreSQL
  • Scaling MySQL-based financial reporting system at Airbnb
  • Scaling to 100M at Wix: MySQL is a Better NoSQL
  • Why Uber Engineering Switched from Postgres to MySQL
• HTTP Caching
  • Reverse Proxy (Nginx, Varnish, Squid, rack-cache)
  • CDN (Akamai)
• Concurrency
  • Message-Passing Concurrency
  • Software Transactional Memory
  • Dataflow Concurrency
  • Shared-State Concurrency
• Event-Driven Architecture
  • Messaging
    • Publish-Subscribe
    • Point-to-Point
    • Store-Forward
    • Request-Reply
  • Actors: Fire-forget and Fire-Receive-Eventually
  • Enterprise Service Bus
  • Domain Events
  • Event Stream Processing
  • Event Sourcing
  • Command & Query Responsibility Segregation (CQRS)
• Load-balancing
  • Round-robin Allocation
  • Random Allocation
  • Weighted Allocation
  • Dynamic Load-balancing
    • Work-stealing
  • Consistent Hashing
  • UDP Load-balancing
• Parallel Computing
  • SPMD (Single Program Multiple Data): The Genetic Pattern
  • Master/Worker Pattern
  • Loop Parallelism Pattern: Extracting parallel tasks from loops
  • Fork/Join Pattern: Good for recursive data processing
  • MapReduce Pattern: Born for Big Data
  • Parallelize the rendering of web pages: Use case of Yelp.com

Availability

• Fail-over
• Replication
  • Master-Slave
  • Tree Replication
  • Master-Master
  • Buddy Replication

Stability

• Circuit Breaker
• Always use timeouts (if possible)
• Let it crash/Supervisors: Embrace failure as a natural state in the life-cycle of the application
• Crash early: An error now is better than a response tomorrow
• Bulkheads: Partition and tolerate failure in one part
• Steady state: Always put logs on separate disk
• Throttling: Maintain a steady pace

Special Thanks

• Jonas Bonér, CTO at Lightbend, for the original inspiration