ClassDojo has a fleet of services that work together to serve user requests as well as complete other data operation tasks. Most of these services are set to auto-scale to better utilize our resources. Part of doing this involves synchronizing a lot of metadata like tags and service ports to keep our configurations up to date. We started thinking about how we could improve distributed runtime changes to our infrastructure-wide config and service discovery as servers join and leave the fleet.

One of the most effective products we’ve launched is Story. As a part of our mission to help teachers, parents and students create incredible classrooms, we released Story as a way to refocus the conversation around the incredible “ah ha!” moments students experience. ClassDojo launched Class Story in September 2015, since then we’ve added Student Story, Story for Parents, School Story, and just recently, Story for student accounts. We decided to use Texture to power Story so we can continue to deliver unique experiences to classrooms worldwide.

We want ClassDojo to be a delightful product for teachers and parents everywhere, and we’ve found that email is an effective channel to showcase awesome features and to offer help if our users need it. These emails are known as lifecycle emails, and the central idea is to send the right content to the right user at the right time.

Up until last year, we had been using third party services for lifecycle communication, but we grew increasingly frustrated with the limitations they presented, and decided to build our own system. So far, we are really happy with its capabilities, performance, and reliability!

This will be a three part blog series covering how we do lifecycle emails at ClassDojo. We’ll start with an overview of the system and its architecture, move on to our experience using Redshift for this system in Part II, and finally explain some unique advantages our system offers compared off-the-shelf third party solution in Part III.