Scaling an app includes many different skills: from writing good code to system administration and architecture. This are the slides of Cristian Planas talk, that took place at itnig on February 20th. Cristian is co-founder & CTO at Playfulbet, and he explained some basic lessons taken from the case of Playfulbet, a social game with more than 150.000 registered users.

1. Die Another Day
Scaling from 0 to 4M
requests per day as a
lone developer

2. I am Cristian…
Gawyn
@crplanas

3. … and this is the story of
how Playfulbet is growing.

4. The growth of Playfulbet is
not so spectacular.
1.5M daily pageviews
4M daily requests

5. 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.

6. Me, scaling in October 2012

7. Me, scaling in February 2014

8. The difference?
One week of October 2012 v.
One week of February 2014

9. We are going to talk about
different techniques for
scaling.

10. But first, we need to
understand how an app
works.

11. The Restaurant
Analogy

12. Requests = Customers
Waiters = Application instances
Food = Data

13. So you want to scale your application?
Meet your next best friend:

14. The application graph

15. The browser graph

16. What happens when
something goes wrong

17. There are 2 ways for improving
load time:
1. Improve app performance
2. Improve your architecture

18. Improving
performance

19. The basic basics
- Use indexes in your DB.
- Optimize your queries:
eager loading, pluck….

20. Cache
In Playfulbet we use
memcached.

21. Materialize
Use the DB –or another
resource- to create a
shortcut to the data you
need.

22. 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.

23. Fake if it’s necessary.
The accuracy of some data is
critical.
But the accuracy of all data is
not always critical.

24. Improving the
architecture

25. In the beginning there was only
one server.
His name is…

26. But the load was too heavy.
So Maradona needed some help in
the back.

27. Obviously, our staging server also
has a cool name.

28. At this point we decided to
move our DB to Amazon.
Good: You don’t need to manage it yourself.
Bad: Latency.

29. The structure kept growing.

30. Our current structure
Proxy
Chat
SSL
Memcached
25 “Frontal”
servers
3 “Back” servers
Redis

31. But this structure can’t
continue.
1.
Our DB has performance
problems.
2. There are cheaper
alternatives.
3. VPS don’t scale CPU.

32. 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.

33. 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.

34. Thanks!