Contribute Media
A thank you to everyone who makes this possible: Read More

Building a reasonably popular web application for the first time.

Description

Erik Näslund - Building a reasonably popular web application for the first time. [EuroPython 2016] [20 July 2016] [Bilbao, Euskadi, Spain] (https://ep2016.europython.eu//conference/talks/building-a-reasonably-popular-web-application-for-the-first-time)

These are the lessons learned when scaling a SaaS web application which grew much faster than any one us could have ever expected.

  • Log and monitor from day one.
  • Things will fail, be sure you know when they do.
  • Choose components which allow language interoperability.
  • Horizontally scalable everything.
  • Plan for database downtime.
  • Have a way to share settings between backend and frontend.
  • Have a way to enter maintenance mode.
  • And more...

My name is Erik Näslund - I’m the co-founder and Head of Engineering at Hotjar.

I'd love to share the lessons learned when scaling a SaaS web application which grew much faster than any one us could have ever expected.

Words like “big” and “popular” carry very little meaning, so let me define how big Hotjar is right now using some numbers.

We onboard about 500 new users on a daily basis. We process around 250 000 API requests every minute. Our CDN delivers about 10 TB of data per day. We have roughly 3 TB of data in our primary data store (PostgreSQL), another 1 TB in our Elasticsearch cluster, and a LOT more on Amazon S3.

These are the key things we wish we knew when we started. They would have made our life so much easier!

  • Log and monitor from day one.
  • Have a way to profile your API calls.
  • Things will fail, be sure you know when they do.
  • Have a way to keep secrets.
  • Everything needs a limit (even if it's really big).
  • Be wary of hitting data type limits.
  • Don't get too attached to a framework.
  • Choose components which allow language interoperability.
  • Horizontally scalable everything.
  • Plan for database downtime.
  • Features are a great way to test things out before launching them to the public.
  • Have a way to share settings between back end and front end.
  • Have a way to enter maintenance mode.
  • Require different quality of code for different parts of your application.
Improve this page