# Composability: How Troupe Tames the Complexity of Distributed Systems
In the world of distributed systems, we often face a dilemma: **the more complex the business logic, the easier the code spirals out of control**. Traditional programming approaches require each node (role) to implement protocol logic independently, leading to maintenance costs that grow exponentially as the number of protocols and roles increases. Eventually, systems become tangled messes—modifying one detail requires synchronizing code across all roles, and debugging a cross-role issue requires tracing multiple independently implemented state machines.
Troupe emerged precisely to break this dilemma. Its core weapon is not simple state machine abstraction, but **composability**. Composability elevates Troupe from a small protocol library to a "construction language" capable of building extremely complex distributed systems. This article explores how composability solves traditional challenges and the revolution in complexity it brings.
## I. The Traditional Way: Logic Dispersion and Maintenance Nightmares
Imagine a simple three-role protocol where Alice, Bob, and Charlie need to collaborate on a task. In traditional implementation, you need to write three separate pieces of code:
- `alice.zig` contains Alice's logic for sending requests, receiving responses.
- `bob.zig` contains Bob's logic for receiving requests, processing, and sending responses.
- `charlie.zig` is similar, but from a different perspective.
If a protocol has M states and N roles, you need to maintain N nearly identical—yet different—state machine implementations. When the protocol evolves (e.g., adding a retry branch), all N pieces of code must be modified synchronously—one oversight can lead to state inconsistency between roles. Worse still, these protocols rarely run in isolation; they intertwine with membership management, failure recovery, and other protocols. Consequently, each role's code becomes a big ball of mud, mixing flags, callbacks, and event handling from multiple protocols.
This decentralized implementation creates several pain points:
- **Redundant Work**: The same logic written N times.
- **Synchronization Cost**: Modifications require coordinating N files.
This file has been truncated. show original