– Shipping an MVP insurance company in 8 weeks with little insurance knowledge

– React Native was used to build mobile apps after a demand for it was seen

– Motivation for using Django and Python to build this site

– The Django admin is used for simple config changes and CRUD operations

– Examples of when they needed to roll their own admin UI due to added complexity

– Stripe is being used to handle the payments with SCA support

– How do you even start an insurance company?

– It’s a monolithic app broken up by Django apps which is a nice way to break things up

– Django apps are a nice stepping stone to maybe microservices due to easy refactors

– What type of Django apps do you have to power your site? There’s 25+ of them

– Not every Django app would end up being its own service in the future

– The MVP didn’t start off with this many apps, it grew organically over time

– Which microservices would you tease out later if it came down to it?

– The split up services would end up having their own dedicated databases too

– The back-end is powered by a GraphQL API

– Using an API back-end came from realizing they are building a platform not an app

– Hole in one insurance isn’t offered, but they did offer rocket launcher insurance

– Graphene is used on the Python side of things and it works nicely with Django models

– On the front-end Relay is being used, but in hindsight maybe Apollo would be better

– The front-end is about 500,000 lines of code (not including node_modules)

– The back-end is about 300,000 to 350,000 lines of code

– There’s about 40-50 top level dependencies in the requirements.txt file

– PostgreSQL is used through RDS on AWS, along with a RedShift cluster

– What is RedShift and how does it help make certain queries much faster?

– They don’t connect to RedShift through Django’s ORM but you do write SQL

– Their financial reconciliation engine has 40-50 million rows and queries are fast

– Celery, Redis, Kubernetes, AWS Lambda, oh my!

– There’s 3-5 web app servers but up to 24 background workers

– Payment handling doesn’t need to happen live as a driver is working

– A majority of things are running on t3 EC2 instances

– Steps taken to safely go from 1 background worker to running many of them

– One mistake they made early on was not having idempotent worker tasks

– Having zero down time deploys with AWS CodeDeploy, but migrations are tricky

– The infrastructure is managed with Terraform, Stuart knows enough to be dangerous

– Trusting your developers to do reviews is important, along with having tests

– There’s a few different environments, such as QA which is after a dev pushes code

– Moving from a git flow model to doing PRs that get merged to a deployed master

– Every pull request that comes in gets a sub-domain that can be directly accessed

– Feature flags are sometimes used, but not with a dedicated library or framework

– Secrets are managed using AWS’ Parameter Store

– The EC2 instances are spun up using pre-baked AMIs, except for the code itself

– They pay somewhere between $10,000 and $50,000 a month on hosting

– How they went from $3,000 to $3 a month from making a database backup change

– Cloudflare is used as their CDN, DNS host, anti-DDoS and SSL certificate service

– The imgix service is used to do on the fly image resizing and optimizations

– Cloudflare is a solid service and competitively priced

– The JavaScript payload for the front-end is about 1MB after being gzipped

– The Next.js library is used to do server side rendering initially

– Mailgun is used for sending emails and Twilio is used for sending text messages

– Sentry.io (hosted version) captures all of their errors with loads of integrations

– DataDog is used for alerting, APM metrics and logging

– It’s valuable to have your metrics and logging on 1 service

-22 – Various alarms and alerts get sent through DataDog

– Health checks are done with Django Health Check, and they query the DB in it

– So far in 2020 they’re operating at 99.99% uptime which is quite the feat

– Checking your database in your health check is totally worth it

– There’s not many live tests that happen in production due to the nature of the app

– Best tips? Release as often as you can and invest in your release process

– That’s also been the biggest pain point as they scaled up to a larger dev team

– Database migrations are run on every deploy

– Check out https://zego.com, their open source work or email Stuart for questions