Distributed Systems Architectures

Architectures in distributed systems describe how components are connected, how data is exchanged, and how servers and clients coordinate. The chosen architecture directly influences fault-tolerance, consistency guarantees, latency profiles, and scalability patterns.

Key Concepts

• Connector: The mechanism for communication and coordination between components (e.g., RPC framework, message queue, shared memory, HTTP). The choice of connector constrains latency, ordering guarantees, congestion control, and fault semantics.
• Idempotent: An operation is idempotent if executing it once has the same effect as executing it multiple times. This is critical in unreliable networks where retries are common. Example: PUT overwriting a value is idempotent; POST appending to a log is not. Idempotency enables retry-on-failure without introducing divergence in replicated state machines.
• Shared Data Space: A persistent coordination medium (e.g., tuple space, shared database, or distributed key-value store) that allows components to interact indirectly without direct coupling. This is common in systems requiring eventual consistency or blackboard-style coordination.

1. Traditional / Layered Architectures

• Organize functionality into layers, typically:
• Application Interface Layer (UI): User interaction and presentation.
• Processing Layer: Query formulation, logic execution, business rules.
• Data Layer: Database or storage backend.
• Communication style is synchronous request-response.
• Tightly coupled: changes in one layer can cascade through other layers.
• Scalability is weak due to vertical integration and cross-layer dependencies.
• Suited for monolithic systems with clear, rigid separation of responsibilities.

2. Object Style Architecture

• Components are modeled as objects with encapsulated state and behavior.
• Interactions occur through procedure calls (often synchronous).
• More decoupled than layered style, facilitating modular development and replacement of components.
• Supports parallel and distributed execution across multiple servers.
• Organization tends to be horizontal: scaling is achieved by instantiating additional objects across nodes.
• Provides natural encapsulation boundaries for fault isolation, but RPC overhead can become a bottleneck if not optimized.

3. RESTful Architecture

• Organized around resources identified by unique URIs.
• Core HTTP methods:
• GET – Retrieve a resource.
• POST – Create a new resource.
• PUT – Update or replace an existing resource.
• DELETE – Remove a resource.
• Stateless: each request includes all necessary information, allowing servers to remain sessionless.
• Scalability is excellent since any server can handle any request without dependency on past interactions.
• Best suited for web APIs, microservices, and large-scale service-oriented architectures.

4. Publish-Subscribe (Pub-Sub) / RTPS

• Asynchronous communication pattern: publishers emit events, subscribers consume them.
• One event may have many subscribers, supporting broad dissemination.
• Topics define communication channels, typically characterized by triples: (name, datatype, quality-of-service).
• Supports persistence: new subscribers can receive historical messages (e.g., durable subscriptions).
• Well-suited for real-time and reactive systems requiring scalability and loose coupling.
• Peer-to-peer topology enables distributed scaling, but requires careful fault-tolerance strategies (e.g., replicated brokers, gossip protocols).

Architecture Comparison