RadPad is an end-to-end rental marketplace focused around people. Renters use RadPad to find a place, sign their lease and pay rent. Landlords use RadPad to list places, sign leases electronically and accept rents.
Jonathan Eppers, Tyler Galpin and Tim Watson founded RadPad in 2012 after attempting to find an apartment in Los Angeles proved to be a terrible experience.
Development began in July 2012 in Venice, California, and was released to friends on Facebook in October.
In January 2013, RadPad had reached over 10,000 downloads and was invited to join the startup accelerator Amplify.LA.
It was around this time that RadPad realized it had a scalability problem – both in terms of listings scraping and traffic through the app.
As a startup, RadPad needed an infrastructure that was highly available, redundant, secure and would automatically scale without human intervention.
And it needed to be done on a minimal budget.
Gunner Technology proposed to move RadPad’s infrastructure to Heroku a Platform-as-a-Solution that was relatively easy to use and could be configured as part of the development process.
The biggest challenge was getting the memory footprint of the application down.
We inherited a Ruby on Rails application running Mongrels that consumed way more memory than the, at the time, allowable 512 mb on Heroku.
The app leaked like a sieve, too.
To combat this in the short term, we migrated to Unicorn application servers instead of Mongrel and used NewRelic to knock off some low-hanging fruit in terms of memory consumption.
We then wrote a script that would constantly monitor and kill Unicorn instances as they approached 100% memory usage.
Long term, we tracked down the leaks and optimized those as well.
Here you will describe the software stack used in the project and why it is the best stack for the job. (Good Question for Gunner to answer)
Heroku allowed us to script deployments and easily clone the production environment for staging and demonstration purposes.
We could also run background dynos that would automatically increase in number to parse rental listings from various sources and replicate the data to our Postgres Database.
If, for example, there were thousands of listings to process, we could run 20 dynos and parse the listings in minutes and then scale back down to a single dyno.
This allowed us to keep cost low as we were only billed for the hours the dynos we running.
We did something similar on the front end to handle spikes in traffic which were occurring frequently as RadPad had begun to be featured in trade blogs and news media.
This was a trail-by-fire project as RadPad was an existing app with growing demand that needed fixing asap.
We attempted to run an agile approach, but ended up having to put out a lot of fires mid-sprint on the existing infrastructure while working on migrating to the new infrastructure.
We had at least one on-call engineer 24/7 who handled the fires while the other engineer worked on the stories in each one-week sprint.
Dary Merckens – Engineer
Cody Swann – Engineer
What did you learn from this project or when overcoming the challenges?
In this project, we learned the value of monitoring apps like New Relic and how invaluable they can be when trying to chase down memory issues.
After the migration, RadPad no longer had a scalability issue and managed 99.999% uptime.
Additionally, while usage increased over 1,000%, cost only increased by 32%.
While at ESPN, Dary and Cody had migrated a large social network to Heroku when the platform was still young.
That gave us the expertise necessary for tackling this project while under fire.