Protecting our platform from spikes in usage by reducing load from the Monzo app 📈 📱

Have you ever opened your app at exactly 4pm the day before payday to use our Get Paid Early feature?

Then you’ve potentially been a member of an effect called the stampeding herd. This is a term we use when large numbers of our customers open the app within a very short time period.

I’m Jacob, one of Monzo’s Staff Engineers, I recently wrote about my path to Staff here. I spend most of my time working on our Borrowing products like loans and overdrafts, but recently I tackled the problem of making our app more resilient to these spikes in app opens.

This blog explores how I built new capabilities to reduce load on our platform before we get overwhelmed, so you can still access and use the most critical parts of the app, and your card continues to work as normal.

Looking forward to picking up any questions that might pop up!

14 Likes

Really interesting article - I am not a tech person per se so might not understand it all fully, but am I right in interpreting it as:

  • When Monzo gets busy you turn on a feature which temporarily degrades (not noticeably) the level of service to account for demand. E.g slower animations, ancillary services loading to protect core functions?

  • Question: How does this tie in with scaling, i.e you see a request for +10k more users than normal and dynamically scale the service to accommodate it.

This seems like it doesn’t scale, and just uses existing resource, albeit with a (not to customer eye) impact.

1 Like

By default we will scale our services to meet additional demand that comes in. 99% of this time this works really well and everything keeps running as normal.

However, occasionally an increase in load can be very sudden (or just very large) and we might not be able to scale quickly enough to meet the demand without some really important things slowing down.

That’s when this load shedding comes in - we can prioritise the most important services in return for a barely noticeable change in performance for less important features. We can use this to give us more time to scale up to meet demand.

3 Likes

I’d have thought that by now, given the paid early feature has been running for years, the daily 4pm load vs the number of active users is easy to systematically predict ?

There must be some big data available to get this almost right (to +/- x% of load)

1 Like

Firstly thanks for taking time to reply, much appreciated. So this is a bit like a “red button” if you see it won’t scale in time.

I’m curious on why this needs to exist though. I would’ve thought you would have previous trends to know when this is likely to happen and when to scale in advance to a tolerant level.

I don’t work in cloud engineering so this isn’t an expert view but I’m still a little curious why this needs to exist.

Is this more about if for example there’s an attack and this prevents total shutdown vs get paid early.

Very very nice job, good to see engineers sharing this info definitely shows why Monzo is way above the competitions.

1 Like

You’re right! And we have a blog on how we do essentially that here.

Perhaps get paid early isn’t a perfect example of when the feature my blog is about is most helpful, we’ve known about that problem for long enough to have more proactive scaling. However, sometimes the reason for a stampeding herd is more surprising than that e.g. if we are having an incident that meant lots of people opened the app to contact support then without the ability to handle a large, unexpected surge in load all those people opening the app might make the problem worse.

We decided to make this investment in protecting critical services when lots of people open the app after reviewing some of our worst historic incidents and deciding that a tool like this could have helped us to recover faster, and with less customer impact. At one point in time Get Paid Early was new and was the cause of some of these incidents so that’s why the example still springs to mind.

4 Likes

Thanks for the clarification. I wondered how the recent (community) post differentiated from the previous (web) blog post, but the clarification explains it isn’t just get paid early - it’s ALL load (amplified by Get Paid early if the timing is wrong)

I think I covered this a bit in my reply to David above - but in short we shouldn’t need this for most things that we can predict, but what about the things we can’t?

Another consideration is that some of the policies I developed have quite a meaningful impact on load for almost no customer impact at all (e.g. not calculating lots of expensive things when your phone receives a push notification). These have so little customer impact that we have even considered having them on all the time. We’ve decided not to do that for now, but if we were planning something that would lead lots of people to open the app at once, then we might choose to turn on some of these policies as well as scaling - certain resources within our platform are hard to scale up dramatically just for a short-term spike in load.

3 Likes

That’s right :+1:

1 Like

Thanks. I actually love this idea and it sounds like it’s going to add real value.

1 Like