8 Palatable scalability

 

This chapter covers

  • Scalability vs. performance
  • Progressive scalability
  • Breaking database rules
  • Smoother parallelization
  • The truth in monolith

“It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness.”

—Charles Dickens on scalability

I’ve had my share of experience with scalability because of the technical decisions I made for Ekşi Sözlük back in 1999. The whole database for the website was a single text file at first. The writes held locks on the text file, causing everything to freeze for all visitors. The reads weren’t very efficient, either—retrieving a single record would be in O(N) time, which required scanning the whole database. It was the worst of the worst possible technical designs.

It wasn’t because the server’s hardware was so slow that the code froze. The data structures and the parallelization decisions all contributed to the sluggishness. That’s the gist of scalability itself. Performance alone can’t make a system scalable. You need all aspects of your design to cater to an increasing number of users.

8.1 Don’t use locks

8.1.1 Double-checked locking

8.2 Embrace inconsistency

8.2.1 The dreaded NOLOCK

8.3 Don’t cache database connections

8.3.1 In the form of an ORM

8.4 Don’t use threads

8.4.1 The gotchas of async code

8.4.2 Multithreading with async

8.5 Respect the monolith

Summary