One Diagram for 38 Services and 12 Nodes
A platform team owns 38 Spring Boot services. Production runs on 12 Kubernetes nodes in two availability zones; each service has a Helm chart, a PostgreSQL cluster, and a Kafka topic. Six services share one PostgreSQL cluster. The architecture review board asks for 'one UML diagram that shows everything: services, interfaces, databases, nodes, and network zones.' A junior modeler delivers a class diagram with 38 classes, 12 nodes drawn as classes, and about 200 associations. Review fails: nobody can tell which service is deployed on which node or which calls cross the zone boundary. The board gives the team two weeks to produce a reviewable structural model. Constraints: the model must stay useful as services move between nodes weekly; the team has no dedicated modeling tool expert.
1. Which structural diagram types should replace the single class diagram, and what question does each answer? Be specific about what goes on each.
Read the worked answer
Replace the single class diagram with two complementary structural models. A component diagram answers 'what are the services and through which interfaces do they depend on each other?' Show each service as a component with provided and required interfaces (ports), and dependencies only where a real call exists. A deployment diagram answers 'which artifact runs on which node, and which nodes communicate across which paths?' Show Kubernetes nodes as nodes (or execution environments), Helm-deployed service artifacts inside them, the two availability zones as nested nodes or groupings, and communication paths labeled with protocols. A composite structure diagram is optional and useful only if one service's internal parts need exposure. The class diagram is retained only for domain/data classes, not for infrastructure. This split answers the board's questions separately: component view for dependency and interface risk, deployment view for placement and zone crossings, and it keeps the model maintainable when services move weekly.
2. Why is a class diagram a poor choice for showing 38 services on 12 nodes, even though classes and nodes can both be drawn as boxes? Identify the UML element misuse.
Read the worked answer
A class diagram is a classifier view: classes describe features, operations, and associations among typed instances. A node is a deployment target that hosts artifacts; drawing it as a class discards the semantics that matter here: deployment, manifest, communication path, and execution environment. The 200 associations are likely associations being used where dependencies or communication paths belong, creating visual noise and false structural coupling. The misuse is treating every box as a class and every line as an association. UML distinguishes node, artifact, component, interface, port, and communication path for exactly this reason. A reviewer cannot answer 'which service is deployed where?' from a class diagram because placement is not a class relationship. The fix is not to relabel boxes but to use the deployment and component diagram elements with their intended semantics; otherwise the model is syntactically UML-looking but semantically wrong, which is worse than no model.
3. Six services share one PostgreSQL cluster. Show how to model this without duplicating the database six times, and state how you would show the weekly node moves without redrawing the whole model.
Read the worked answer
Model the PostgreSQL cluster once as a node or database component/artifact in the deployment view, and draw six dependencies from the six service artifacts to that single element. In a component view, show a shared database component with six required interfaces or dependencies; do not clone the database symbol. For weekly node moves, keep a stable component/deployment specification model and produce per-environment deployment diagrams, or use deployment-spec instances for dev, staging, and prod. The component model remains unchanged; only the deployment diagram changes, and changes are localized to artifact-to-node deploy relationships. If the tool supports it, use a template deployment diagram with parameters for node names. Add a note or constraint that the database is shared and is a single point of failure. This preserves one source of truth for the database and prevents the sixfold duplication that made the original diagram unreviewable.