I’ve just been reading through the job posts on Monzo’s careers page & I thought I’d share the current list of tools & technologies from Monzo’s technology stack (a couple of which - in bold - weren’t mentioned in this blog post), before the Backend Engineer role is taken down, if it ever is
@anon50039658@anon38211169 Would be awesome to see an update to this with the impending CA roll out to see how/if you have had to change the way your infrastructure runs to scale differently to the pre paid.
@anon77247897 - thank you kindly for this. The content is excellent. A few questions for you. People related questions.
(1) What is the impact of the architecture Monzo has set out, on how product teams have been structured?
(2) What has been the biggest challenging in onboarding engineers with this, architecture?
(3) Does each engineer have accountability for a few micro services?
I don’t think the architecture has driven the design of our organisational structure, but it also has not constrained it. As you may know, there is no “engineering team” at Monzo. Instead, there are lots of teams, many of which each have some engineers. Our architecture has been really useful in letting us make those teams as autonomous and decoupled as possible.
With several hundred services, it’s becoming increasingly impractical for every engineer to know even what functionality exists within the platform. Of course, they have access to all the code, but it’s a bit like an operating system where there’s just lots of functionality that you may not be aware of. I personally am often pleasantly surprised to discover some useful nugget of functionality that already exists.
Each team has responsibility for a set of services. There is no responsibility on an individual for an individual service.
FYI, that case study and the architecture diagram are both at least somewhat incorrect. Daniel mentioned he had not seen the case study before, and that they did not use CloudHSM (which is mentioned in both the diagram and the case study).
