How we built a backend for our £20 million crowdfunding round

A few of our engineers will be sharing an insight into the technical work we did for crowdfunding :hammer_and_wrench:

First up, @robinb explains how we architected a backend to support the investments!


Great insight love the detail :slight_smile:

Great detailed post :muscle:

Very in-depth coverage of the tech behind the seamless £20 mil crowdfunding :sunglasses::hot_coral_heart:

Absolutely awesome, loving the in depth technical coverage :hot_coral_heart:!

Pretty amazing!

Very cool. I’m curious what notes tool was used for the written proposal, is it Notion?

It’s Dropbox Paper :relaxed: We do love Notion here too though!


Ah nice. All that talk of Cassandra and I’m just interested in the notepad!


Brilliant article. And it all seemed so simple from an investor’s point of view. The planning and hard work certainly paid off. A great way to invest - I hope it can be used again.

1 Like

Really interesting article, have loved how open Monzo has been in the past with it’s internal operations, so it’s great to see you being just as open about the backend stuff as well.

How long did building and testing take for all of this?

NSQ does not provide any guarantees on delivery. It is a great queue system, particularly for publishing times - very fast, but messages can be lost in the case of a single failed node. Did you guys do anything to prepare for that case?

1 Like

As you have already created an infrastructure for this, did you consider to provide it to your partner also?

It can be an application on your marketplace that you are considering and it can help you both as:

  • You can reuse most of the existing solution in a similar way
  • Your partner can reuse your solution for a bigger/heavier investment rounds
  • They can also provide an easier Monzo integrated payment which is good for their customers
  • You can get more customers as you provide easier payments, loans etc.
1 Like

Smoothly - hmmm it wasn’t smooth for everyone, when some people were unable to click the link and access the pg. good planning, and yes your system worked. But there was issues.

Why nsq and not Kafka which I believe you use extensively?
Did you use the same etcd cluster which runs your control-plane. Or did you spin up a new etcd cluster?

Very interesting. These are exactly the sort of architect decisions we are making too. Thanks for the insight.

1 Like

Crowdfunding took quite a long time to prepare due to all the operational and legal work that goes into a project like this so we had more time than we needed. That being said it took us about 2-3 months to get all the engineering work completed.

While we could have had everything ready sooner we realised that a lot of the work we were doing to optimise our platform and run load tests were great preparation for dealing with the growth of the company. We recently had a retrospective about this project and while its really difficult to say if a project of this scale went we were very happy with how smoothly everything went and how much we were able to learn from the experience.


Great question, the main goal of this architecture was to ensure that the rest of the bank was as isolated as possible from the investment system. That being said reliably processing investment was also important to us! As we wrote all investments to Cassandra before publishing anything onto NSQ we could have recovered from a failed node by replaying investments from the ‘pre-investment’ database. Luckily nothing like this happened so we did not need to reply any events!

The main reason we chose NSQ was that it can be very fast and its a system we have been running for a long time (Kafka is a relatively recent addition to our platform). While Kafka would almost certainly have been better suited to deal with some of the failure scenarios such as the one you mentioned I would still stand by our use of NSQ for such a high traffic but short lived system.


We use both NSQ and Kafka extensively, NSQ was actually quite a long time before we started using Kafka!

Regarding etcd we have multiple clusters which are used for different purposes. The cluster for running the control plane is completely separate from the cluster used for synchronisation.


I am really sorry you didn’t have a great experience. We spent a long time testing everything to try and fix any bugs before we launched crowdfunding but in a couple of areas we didn’t do enough.

As I mentioned above we has a retrospective after the project ended and this was one of the points that was raised. Based on those discussions we now have plans in place to try and prevent these issues from happening again.