One per team sounds about right, unless there are some components that don't fit together in the same runtime (e.g. a data lookup with a little business logic might not fit with a module sending out emails). That said libraries go a long way to reduce the dependency graph and prevent developers from creating unnecessary edges by randomly autocompleting code.

IME we had multiple services for each team. But we were in the process of carving several mutually incompatible whales into common, shared services, YMMV. So we had one team maintaining each whale, and our senior engineers would collaborate to identify pieces that could be cut from each and replaced with a common service. If the innards of one whale matched our service better than the others, that whale's team got to write the service. Eventually all the teams would port their products to the new, resulting service.

This meant, for example, that my team, had our whale, an audio transcoding service, an automated transcription service, a post-phone-call messaging service, and several data integrations.

If you need a whole team to do nothing but maintain a service, it seems to me like you built it to do too much.

So you would hard couple your architecture to your current org structure?

Software architecture always mirrors org structure anyway. That’s Conway’s law.

and boy if it doesn't mirror org structure. you get pain :)

multiple services per team are trickier. also depends on their complexity. sometimes you can't get around it.

it also depends on your infrastructure to manage services. if setting up, managing, deploying and monitoring a service is cheap it can make sense.