I assume they're mostly RPC, and one procedure is one 'microservice'.
There seems to be a bit of difference in what people mean by 'microservices' - some orgs will have a few REST collections per 'service' so you might end up with 'users', 'products', 'transactions' as your three services, and it being totally unimaginable that you'd ever break 1000.
I'd argue that's still a Service-Oriented Architecture (SOA), but I'm sure it's not anywhere near as 'micro' as what Monzo counts over a thousand of.
Microservices generally have 0-10 RPC handlers (we use https://github.com/monzo/typhon). We have a lot of different object types at Monzo, it goes way beyond 'transaction' or 'user' and each object type is going to be at least one service, but can be several. Services that mostly just consume off queues are often separated from services that handle requests so they can scale separately.
Oh I wasn't suggesting user/product/transaction were what Monzo would use! (Should have made that clearer since 'transaction' is right domain...) Just the first things that came to my mind for very basic sort of service splitting that I'm familiar with.
Thanks for replying, that does clear things up. My experience didn't really embrace RPC, so used gRPC for one small bit (< all of the service that contained it as I recall) but most was JSON HTTP APIs - the service boundaries pretty much just being team boundaries, though some (incl. mine) had a few services to the team.
