Autoscaling Monzo: How we optimise our platform to be just the right size

Check out our latest technology blog post, this time from our Platform team!


Things I understood from this article: Monzo is run from the back of a Van.


while (monzo == exists) {
    if (BoxSize > VanCapacity) {
    } else {

It could just be me, but I found this article quite hard to follow and suspect most other customers would as well.

The article either needs to be written with a lot less jargon and technical terminology so that the average person can follow it in plain English or it needs to be more technical and in depth for techies

At the moment, it seems so high level, that most of what’s discussed should be quite self evident to those familiar with the terminology (or even just the wider field in general) but confusing to everyone else.

Good feedback, thanks!

I think it’s a bit of a balancing act for things like this. It’s certainly written for a technical audience who already understand what Kubernetes containers, etc. are (I certainly don’t). And they don’t need us to make it much more simpler than it is here.

But I can also see the case that the average Monzo user might be interested in this kind of thing, but struggle to get their head around the jargon.

So do we make it super basic (which would mean basically having to give a mini crash course in the Monzo Platform), or accept that it’s for a sub-audience familiar with the technicalities? We opted for the latter here, which is why we’ve shared it on our more techy channels (here, and Making Monzo) rather than our main channels.


Please dont make them super basic, they are good as they are. They are clearly not aimed at everyone, in fact probably only a small subset of users and probably actually a few non-users too who are interested in learning. I think its fine and one of the things I love about Monzo is when they share the technical details and inner workings without being bogged down as a how-to. But then again I am very much in the target demographic for this post.


Yeah don’t dumb it down, whilst bits of it needed a bit of thinking I found in the main I could follow it and got the gist


Always got my proof reading head on and I think there’s a couple of rogue apostrophe:

For example, if we wan’t only a single replica of a service to unavailable at a time, we’d configure something like this:

In itself this is far from ideal, but with the three VPA components configured to vertically scale themselves, we found a degenerate edge case whereby the history load on start failed, leading to the VPA recommender building it’s model from scratch on each restart, leading to volatile recommendations and increased evictions, leading to recommender itself being evicted.

Might want to consider breaking that last one down into multiple sentences or using semi colons for variety? :wink:


Good spots, Colin. Thanks!


I work with k8s for my paycheck. I appreciate these crunchy posts and, in fact, the tech channel is the only part of the Monzo blog I consume :slight_smile: This one was particularly interesting as I just spent the day getting a VPA deployment ready to trial in our dev environments.

I recognize that many people will find the specialized terminology difficult to follow. However I think attempting to communicate these concepts purely with everyday language will lead to a post that is not clear and interesting to people familiar with the topics while still being confusing to the layman.


Yeah I work as a non-technical person in an infrastructure team that work with Kubernetes.
I could have done with ‘just a bit more padding’ (with some technical concepts fleshed out more). But I appreciate the depth it went to and they shouldn’t change.

Maybe up the top of each article you could have a brief ‘non-technical abstract’?