Starting to think about scaling (Tue Feb 8, lect 7) | previous | next | slides |

Sinatra, Service Oriented Architectures and scaling

Logistics

  • Reminder of how participation homework works
  • Thoughts about “Begin”
  • Why were people asking about Gemfiles? What is a Gemfile?

Walk through of a basic scenario

  • Baseball scoring application - First cut
    • Millions of fans are constantly refreshing page to see current score in real time as the game progresses
    • A local official enters stats as the game progresses
    • Default implementation with a single “monolithic” app
    • How will things break down?
  • Assuming:
    • variable t = total number of teams in this league (guess 100)
    • variable s = number of games happening simultaneously (guess: 4)
    • Given a scoreboard app written in Sinatra
    • What is a good assumption for the number of times per second the page will refresh?

Review of everything so far

  1. What a web server is and how Sinatra helps you create one
  2. Meaning of the URL
  3. ActiveRecord as the bridge between Ruby and the relational database
  4. The relationship between the client and the server
  5. How Unit testing is done with Minitest/Spec et al.
  6. The idea of Test Driven Development
  7. HTTP and it’s different Verbs like GET, PUT, POST etc.

Non Scalable Architecture (good starting point)

  • A Web Server (aka App Server) runs your code.
  • That server is connected by network to a database server.
  • There are background processes and they run on the same server
  • Scaling it follows a path of least resistance

Scalable Architecture (where you will end up)

  • As load becomes greater, capacity is added where it is needed
  • A “load balancer” sends traffic to different servers
  • A “cache service” like Redis reduces the number of requests to the database
  • And background processes are also replicated over multiple servers
  • This kind of configuration is typical of many sites
  • But what happens when the database cannot carry the load by itself?
  • Managing the monolithic code base itself also becomes a problem
  • Test suites take longer to run.

Getting from here to there

  • It is natural to begin with a monolithic MVC design. This is true if you are implementing in Ruby/Sinatra, Ruby on Rails, Node or any other language.

A Service Oriented Architecture

  • Some or all the models could be broken off into services, one model per service, or more likely, several models in one service.

  • This is just a start. We will build on this scheme and use this in NanoTwitter

Thank you. Questions?  (random Image from picsum.photos)