Die Another Day: Scaling from 0 to 4 million daily requests as a lone developer by Cristian Planas

Die Another Day

Scaling from 0 to 4M requests per

day as a lone developer

I am Cristian…

Gawyn

@crplanas

… and this is the story of how Playfulbet is

growing.

The growth of Playfulbet is not so

spectacular.

1.5M daily pageviews4M daily requests

But the interesting part of this story is the small

resources we had.

This is not only the story of how Playfulbet grows, but how I grow.

Me, scaling in October 2012

Me, scaling in February 2014

The difference?

One week of October 2012 v.

One week of February 2014

We are going to talk about different

techniques for scaling.

But first, we need to understand how an app

works.

The Restaurant

Analogy

Requests = CustomersWaiters = Application

instancesFood = Data

So you want to scale your application?

Meet your next best friend:

The application graph

The browser graph

What happens when something goes wrong

There are 2 ways for improving load time:

1. Improve app performance

2. Improve your architecture

Improving performance

The basic basics

-Use indexes in your DB.-Optimize your queries: eager loading, pluck….

Cache

In Playfulbet we use memcached.

Materialize

Use the DB –or another resource- to create a

shortcut to the data you need.

An example

A bet is made on an option.An option exists on a market.A market exists on an event.

An event exists on a competition.A competition exists on a sport.

All the bets should show an icon depending of the sport.

Fake if it’s necessary.

The accuracy of some data is critical.

But the accuracy of all data is not always critical.

Improving the architecture

In the beginning there was only one server.

His name is…

But the load was too heavy.

So Maradona needed some help in the back.

Obviously, our staging server also has a cool name.

At this point we decided to move our

DB to Amazon.

Good: You don’t need to manage it yourself.

Bad: Latency.

The structure kept growing.

Our current structureProxy

ChatSSL

Memcached

25 “Frontal” servers

3 “Back” serversRedis

But this structure can’t continue.

1. Our DB has performance problems.

2. There are cheaper alternatives.

3. VPS don’t scale CPU.

In the very near future:

1. We are moving to dedicated servers.

2. We will use slave DBs for reads.

3. We will have someone in charge of the system

administration.

So this is the end of me as the only technical

guy in Playfulbet.

And this is why I wanted to share this

story with you.

Thanks!