Sometimes a single service isn't enough to meet our performance or operational needs. That's when we have to scale our solution horizontally, by getting multiple services working together in an system.
There are two reasons to add a new service into an system:
when you've hit a performance/scalability bottleneck
to gain operational benefits (for example, to separate your batch processing from your main service)
The simplest ecosystem we can visualise involves just two systems. We can imagine them being connected via a "cable" which extends from an external dependency in a component in Service-B to an endpoint in Service-A's base.
One of the advantages with Polylith is how easy it is to share components across multiple services within a workspace. It's a component's functional and stateless nature that makes it perfect for reuse. For example, if both Service-A and Service-B need to access the same database, then they can use the same database component.
Hopefully the building block metaphor has given you a high-level understanding of the Polylith architecture.
Now let's take a closer look at how Polylith structures your code, and gives you a workspace to play with these building blocks.