How small is small enough? How small is too small?
This is a question I consider when I'm mapping domains into services, then decomposing those services into microservices. I specialize in event-driven distributed systems, and I've found at scale the right size is critical.
In the pre-coding-agent "olden times" my rule of thumb was: any service should be small enough to fit in the head of a single engineer. The cognitive load is low enough that one person can read the code and reason about the failure modes. In broken-prod situations, this is critical: anyone can trace through the execution path to find and fix the root cause.
But you can go too far. When you over-decompose, the complexity doesn't go away, it just moves out from the individual services into the space between them. Each service is easy to understand, but you can get lost tracking functions across a chain of interactions. If you're fixing a simple bug and it touches three services and needs a coordinated release, perhaps you've gone too far. This is the kind of thing that you feel at 3am when a critical trace spans nine hops and two time out.
As it turns out, "small enough to fit in one head" is also a useful shape for agentic coders. Agents, like people, have a limited context window. You can only shove so much in there before performance degrades and it loses track of the details. By decomposing into right-sized services I can focus the agent on the relevant subset of the code. I've had great success with that, even in a large, legacy mono-repo.
This also gives me a different way to allocate my own limited cognitive capacity. After years of having teams produce far more code than I can ever personally understand, I found it effective to focus on the boundaries rather than the service internals. I can't attest to every line of code, but I understand the contracts and how the system itself works. This is the critical skill when you're deciding where you need to invest your limited time and development resources.
So I've revised the rule of thumb: services should be small enough to fit in the head of a single engineer AND into the context window of a single agent. Those used to be roughly the same size. They aren't anymore, and the gap is growing. A million-token window holds far more than I can. If you size to agent capacity you'll build services no human can hold, and you'll find out at the worst possible time.
The human bound is the smaller one. It's still the one that counts.