A Patreon Architecture Short
Patreon recently snagged $30 Million in funding. It seems the model of pledging $1 for individual feature releases or code changes won't support fast enough growth. CEO Jack Conte says: We need to bring in so many people so fast. We need to keep up with hiring and keep up with making all of the things.
Since HighScalability is giving Patreon a try I've naturally wondered how it's built. Modulo some serious security issues Patreon has always worked well. So I was interested to dig up this nugget in a thread on the funding round where the Director of Engineering at Patreon shares a little about how Patreon works:
- Server is in Python using Flask and SQLAlchemy,
- Runs on AWS (EC2, RDS (MySQL), and some Redis, Celery, SQS, etc. to boot).
- A few microservices here and there in other languages too (e.g. real time chat server with Node & Firebase)
- Web code is written in React (with some legacy code in Angular). We tend to use Redux for the non-component pieces, but are still trying out new React-compatible libraries here and there.
- iOS and Android code are written in Objective-C and Java, respectively.
- We use Realm on both platforms for data storage
- Most of the rest is pretty standard modern project stuff (CocoaPods for iOS, Gradle on Android, etc.)
For this time period it seems like a good set of technologies to use for the type of application Patreon is. It's interesting to see Angular as referred to as legacy code. React seems to be winning the framework wars.
The use of Realm is notable on the mobile platform as a common storage layer. Realm's simplicity is attractive.
The use of microservices may have helped Patreon dodge the Parse closing down bullet. Instead of trying to find one backend to rule them all they picked Firebase, a more targeted technology, to implement a specific feature. Service diversification is a great way to manage service failure risk.
