When a shop is split into microservices, the important questions are: which services exist, what interface does each one offer, and what does each one depend on? A UML component diagram answers exactly that, using balls for interfaces a component provides and sockets for interfaces it requires.
This sample shows an API gateway in front of six services, an event broker and an external payment provider.
1. The Diagram
Clients only see one interface: HTTPS /api, provided by the API Gateway (highlighted). It checks tokens, applies rate limits and routes each call.
The gateway requires three interfaces: ITokens from Identity, ICatalog from Catalog and IOrders from Order. Each ball-in-socket is an assembly connector: one side needs what the other offers.
Order Service is the busiest: it requires IInventory to reserve stock, IPayments to take money and IEvents to publish OrderPlaced.
Payment Service wraps the external Payment Provider, so only one component knows the card network API.
Notification Svc also requires IEvents: it listens on the broker and never calls Order directly. That keeps the two decoupled.
Each service note says which database it owns; no two services share a database.
2. How to Read It
Think of a plug and a wall outlet. Anything that provides the same interface can be swapped in without changing the components that require it, which is the whole idea of a component.
3. Variant: White-Box View of One Service
Component diagrams nest. Zoom into Order Service and the outside interfaces attach to ports (small squares on the border). Inside, the REST controller hands requests to the order logic, which uses a repository and three outbound adapters. The outbox publisher writes events in the same database transaction as the order, then relays them to the broker, so an order is never saved without its event.
4. Pros and Cons
Pros
Shows dependencies and contracts, which is what architects argue about.
Interfaces make coupling explicit: count the sockets to see how many things a service needs.
Nests well, from system level down to one service.
Fits naturally with API specs (OpenAPI, protobuf, AsyncAPI) named on each interface.
Good input for team boundaries: one team per component.
Cons
Says nothing about where things run; that is the deployment diagram.
No ordering or timing of calls.
Ball-and-socket notation is unfamiliar to many readers; plain arrows are often used instead.
Hard to keep complete in a large system with dozens of services.
5. When to Use It
Use it when
Designing or reviewing service boundaries and APIs.
Checking for cycles or a service that depends on everything.
Planning to replace one component (for example a payment provider).