At ClassDojo, we’ve recently been building out our push notification infrastructure. Our plans required a rate limiter that met the following criteria:

• Distributed: The rate limiter can be shared across multiple processes. This necessitated the use of a external key-value store – we chose Redis, because we use it elsewhere in the stack.

• Rolling Window: If we set a maximum of 10 message per minute, we didn’t want a user to be able to receive 10 messages at 0:59 and 10 more messages at 1:01.

• Minimum Distance Between Messages: Regardless of what overall rate we chose, we wanted to also enforce a minimum distance between consecutive messages, so that teachers wouldn’t get an annoying burst of several sounds or vibrations while busy in the classroom.

We looked around at the available rate limiting options, but what we found on NPM didn’t meet the above requirements. So we decided to write our own, which you can download here.

We have thousands of tests and regularly deploy to production multiple times per day. This article is about all the crazy things we do to make that possible.

How we test our API

Our web API runs on node.js, but a lot of what we do should be applicable to other platforms.

On our API alone, we have ~2000 tests.

We have some wacky automated testing strategies:

Fs-Tail is a simple library we wrote that provides tail -f-like functionality using Node’s v0.10+ streams and fs modules. Install via npm:

1

npm install fs-tail

As ClassDojo has grown, we’ve spent a lot of time improving our analytics infrastructure. An important part of those efforts has been building a pipeline that can quickly transfer hundreds of gigabytes of data from our primary Mongo cluster to Redshift.