Distributed Architectures and System Models

Introduction

Distributed computing studies systems whose components execute on multiple networked computers but cooperate sufficiently to appear, to some extent, as one system. The computers may be located in the same data centre, across regions, or at the edge of a network. Distribution enables scalability, availability, geographical reach, resource sharing, and organizational independence. It also introduces partial failure, communication delay, concurrency, inconsistent state, and difficult reasoning about system behaviour.

Architecture describes how system responsibilities are divided among components and how those components communicate. A system model provides abstractions for analysing the environment in which the architecture operates. The two must be considered together. For example, a microservice design may be logically modular, but its operational behaviour depends on network latency, service discovery, replication, failures, and deployment topology.

This chapter compares major distributed architectures: client–server, multi-tier, peer-to-peer, service-oriented, microservices, event-driven, serverless, and decentralized systems. It then develops physical, architectural, interaction, and failure models. Finally, it applies CAP and PACELC reasoning to architectural choices.

Learning Objectives

By the end of this chapter, the reader should be able to:

1. Explain the purpose and characteristics of major distributed architectures.

2. Distinguish physical, architectural, interaction, and failure models.

3. Analyse synchronous and asynchronous communication and their consequences.

4. Evaluate replication, partitioning, coordination, and consistency choices.

5. Apply CAP and PACELC reasoning to distributed-system designs.

6. Select an architecture using performance, reliability, governance, and operational criteria.

1. Foundations of Distributed-System Architecture

A distributed system consists of independent processes that communicate through a network and coordinate their actions. No process has complete knowledge of the global state, and there is no universally reliable assumption about communication time or component availability.

An architecture answers several questions:

• Which components exist, and what responsibilities do they have?
• Where is state stored?
• Which component initiates interaction?
• How are components located and authenticated?
• How are failures detected and recovered?
• Where are consistency, security, and business policies enforced?

The architecture should not be confused with deployment. A logical service may be deployed as a separate container, several replicas, or a function invoked on demand. Conversely, several logical components may run in one process. Architecture is therefore a design abstraction, while deployment describes its physical realization.

Important architectural properties include:

• Scalability: the ability to handle increasing workload by adding resources or improving resource efficiency.
• Availability: the probability or proportion of time a service is usable.
• Reliability: the ability to perform correctly over a specified period.
• Consistency: the degree to which observations of shared state conform to a specified ordering or rule.
• Latency: elapsed time between a request and its response or between an event and its processing.
• Elasticity: the ability to expand and contract capacity in response to demand.
• Autonomy: the degree to which components can evolve and operate independently.
• Operability: the ease of deploying, observing, securing, and repairing the system.

These properties compete. Strong coordination may improve consistency but increase latency and reduce availability during network partitions. Independent services may improve team autonomy but create more network calls and operational complexity.

2. Major Distributed Architectures

2.1 Client–Server Architecture

In a client–server architecture, clients request services and servers provide them. A client may be a browser, mobile application, desktop program, or another service. A server usually owns data or processing capabilities and exposes an interface such as HTTP, RPC, or a database protocol.

The model is simple and widely understood. Centralized authorization, data management, and policy enforcement are advantages. Servers can also be replicated behind a load balancer. However, a single server or database can become a bottleneck or single point of failure. Scaling the server vertically is often easier initially but may become expensive or physically limited.

The client–server relationship is not necessarily one-to-one. A client may contact several servers, and a server may serve thousands of clients. A modern web application is often client–server at the outer boundary and multi-tier or microservice-based internally.

2.2 Multi-Tier Architecture

Multi-tier architecture separates a system into logical layers, commonly:

1. Presentation tier: user interface and interaction handling.

2. Application or business tier: business rules and workflows.

3. Data tier: databases, files, indexes, and durable storage.

A request may travel from a browser to a web server, then to an application server, and finally to a database. Separation improves maintainability, security boundaries, and independent scaling. For example, stateless application servers can be replicated without replicating the user interface or database in the same manner.

The principal limitation is that tiers can become rigid or chatty. A transaction crossing many layers may incur latency. The architecture may also preserve a centralized data tier that limits availability and geographical scale. Layering is a useful discipline, but it should not become an excuse for unnecessary indirection.

2.3 Peer-to-Peer Architecture

In peer-to-peer (P2P) systems, nodes can act as both clients and servers. Resources and responsibilities are distributed among peers rather than concentrated in a permanent central server. Examples include content distribution, distributed file sharing, some communication systems, and blockchain networks.

P2P systems can scale by adding peers and can remain useful despite individual node failures. They may also reduce infrastructure cost. Their difficulties include peer discovery, incentive design, variable node capacity, malicious participants, inconsistent data, and complex membership management.

P2P systems may be structured, using a defined overlay such as a distributed hash table, or unstructured, using probabilistic search and flooding. Structured overlays offer more predictable lookup behaviour but require more maintenance when membership changes.

2.4 Service-Oriented Architecture

Service-oriented architecture (SOA) decomposes enterprise capabilities into services with explicit contracts. Services are usually relatively coarse-grained and may be shared by many applications. Communication can use REST, messaging, SOAP, or enterprise integration middleware.

SOA emphasizes interoperability, reuse, governance, and integration across heterogeneous systems. It is particularly useful where multiple business units or legacy platforms must exchange information. An enterprise service bus may provide routing, transformation, monitoring, and policy enforcement.

Centralized governance can improve consistency but can also create bottlenecks. Shared services and elaborate middleware may create hidden coupling. SOA is therefore not simply “many services”; it is an organizational and integration approach in which contracts and governance are central.

2.5 Microservices Architecture

Microservices structure an application as a set of small, independently deployable services organized around business capabilities. Each service generally owns its data and exposes a narrow interface. Services communicate through synchronous APIs, asynchronous messages, or both.

Potential advantages include independent deployment, technology flexibility, team autonomy, and selective scaling. A payments service can be scaled or changed without redeploying the catalogue service. The disadvantages include distributed transactions, versioned contracts, network failures, duplicated data, observability requirements, and increased operational burden.

Microservices are not automatically superior to a modular monolith. A well-designed monolith may provide simpler transactions and lower latency. Microservices become valuable when organizational boundaries, scaling requirements, or independent release needs justify their cost. Poorly decomposed microservices can produce a distributed monolith: many services that must be deployed together and communicate through fragile chains.

2.6 Event-Driven Architecture

In an event-driven architecture, producers publish events describing facts, and consumers react to them. An event such as `OrderPlaced` may be consumed by inventory, billing, notification, and analytics components. Producers need not know all consumers, reducing direct coupling.

A broker or event log may retain events, allowing replay and delayed consumption. This supports asynchronous processing, temporal decoupling, and integration with analytics. It also introduces eventual consistency, duplicate delivery, ordering questions, schema evolution, and more difficult debugging.

A command requests that an action be performed; an event records that something has happened. Confusing these concepts can produce unclear ownership and unsafe retries. Consumers should normally be idempotent: processing the same event more than once should not create an incorrect result.

2.7 Serverless Architecture

Serverless computing allows developers to deploy functions or managed services without managing the underlying servers. The provider allocates resources, scales instances, and charges according to execution or resource usage. Function-as-a-Service platforms commonly invoke code in response to HTTP requests, queues, schedules, or events.

Benefits include rapid delivery, elastic scaling, and reduced infrastructure administration. Limitations include cold-start latency, execution limits, provider-specific interfaces, difficult local debugging, distributed observability, and potential cost unpredictability under sustained load. Serverless is best understood as an operational model, not as an absence of servers.

Serverless systems often combine functions with managed databases, queues, object stores, and API gateways. Architecture must still address authentication, authorization, idempotency, retries, data consistency, and failure recovery.

2.8 Decentralized Architecture

A decentralized system distributes authority and decision-making among independent participants. No single operator necessarily controls membership, validation, or state. Blockchain and distributed-ledger systems are prominent examples, although decentralization also appears in federated networks and some P2P systems.

Decentralization may improve resistance to censorship, unilateral failure, and organizational dependence. Its costs include lower throughput, more complex consensus, governance disputes, privacy challenges, and difficult upgrades. A system can be technically distributed but administratively centralized; decentralization must therefore be evaluated in terms of control, validation, ownership, and governance.

3. System Models

3.1 Physical Model

The physical model describes the actual or assumed deployment environment: hosts, processors, memory, networks, storage devices, data centres, availability zones, and geographical regions. It also identifies co-location and connectivity.

A system deployed across three availability zones has a different failure exposure from one deployed on three virtual machines in the same rack. Replicas placed in one region may survive a process failure but not a regional outage. Physical diversity is therefore relevant to fault tolerance.

Important physical questions include:

• Are nodes homogeneous or heterogeneous?
• Are networks local, wide-area, wireless, or intermittently connected?
• Are clocks synchronized accurately enough for the intended application?
• Are resources dedicated, virtualized, or shared?
• Which failures can affect multiple nodes simultaneously?

3.2 Architectural Model

The architectural model describes components, roles, boundaries, interfaces, data ownership, and communication paths. It can represent clients, servers, brokers, databases, replicas, gateways, and control planes.

A useful architectural model distinguishes data plane and control plane. The data plane processes ordinary user traffic; the control plane manages membership, configuration, routing, and policies. A control-plane failure may prevent reconfiguration even if existing data-plane traffic continues.

Architectural models should also expose trust boundaries. A service inside one administrative domain may trust infrastructure differently from a service communicating with an external partner.

3.3 Interaction Model

The interaction model specifies how processes communicate and coordinate.

In a synchronous interaction, a caller waits for a response, often subject to a timeout. Synchronous calls are easy to understand but couple caller progress to network and callee availability. A timeout does not prove that the callee failed: the request may have been processed while the response was delayed.

In an asynchronous interaction, a sender continues without waiting for immediate processing. Queues and event logs provide buffering and temporal decoupling, but introduce delivery, ordering, and retry concerns.

Interaction models also address timing assumptions. In a synchronous model, known bounds on processing and communication time may be assumed. In an asynchronous model, no fixed upper bound is assumed. Real systems are often partially synchronous: messages usually arrive within practical bounds, but those bounds cannot always be guaranteed.

The distinction between safety and liveness is fundamental. Safety means that something bad never happens, such as applying an invalid payment twice. Liveness means that something good eventually happens, such as a valid message eventually being processed. Timeouts, retries, and consensus protocols must be designed with both properties in mind.

3.4 Failure Model

A failure model states what can go wrong and what the system assumes about those failures.

• Crash failure: a process stops and performs no further actions.
• Omission failure: a message is lost or a response is not sent.
• Timing failure: a process or message exceeds an assumed time bound.
• Authentication or Byzantine failure: a component behaves arbitrarily, possibly sending conflicting or malicious information.
• Network partition: communication paths between groups of functioning nodes fail.
• Correlated failure: multiple components fail because of a shared cause, such as a region outage, software defect, or credential compromise.

Failure detectors are generally imperfect in asynchronous systems. A detector may suspect a healthy but slow process. Consequently, systems should avoid treating suspicion as proof. Idempotent operations, leases, fencing tokens, quorum protocols, circuit breakers, and reconciliation mechanisms help limit the consequences of uncertainty.

4. Replication, Partitioning, and Coordination

Replication stores multiple copies of data or computation. It can improve read performance and availability, but replicas must be synchronized. Synchronous replication waits for specified replicas before acknowledging a write; asynchronous replication acknowledges earlier and propagates later.

Partitioning, or sharding, divides data among nodes. It increases capacity and reduces the amount of data managed by each node. A partition key should distribute load evenly while supporting important queries. Poor key selection creates hotspots.

Coordination is required when several processes must agree on ownership, ordering, or state. Consensus protocols and quorum techniques are examples. If a system uses a write quorum of size W and a read quorum of size R across N replicas, the common overlap condition for strong read visibility is R + W > N, assuming the protocol and failure model support the required semantics. This condition alone does not guarantee linearizability; conflict resolution, replica freshness, and concurrent writes also matter.

A distributed transaction may use two-phase commit, sagas, transactional messaging, or an application-specific workflow. Two-phase commit can provide atomic commit across participants but may block during coordinator failures and adds coordination overhead. Sagas divide a business transaction into local transactions with compensating actions; they improve availability and autonomy but compensation may not perfectly undo side effects.

5. CAP Theorem and PACELC Reasoning

5.1 CAP

CAP concerns a distributed data system in the presence of a network partition. Its three properties are:

• Consistency (C): every operation observes a single, current ordering of data, commonly interpreted as linearizability.
• Availability (A): every request to a non-failing node receives a non-error response.
• Partition tolerance (P): the system continues operating despite communication loss between groups of nodes.

The theorem states that when a partition occurs, a system cannot simultaneously guarantee both strong consistency and availability. This is not a license to label an entire product simply “CP” or “AP.” Different operations, databases, and configurations may make different choices.

A CP design refuses or delays some operations during a partition to preserve consistency. An AP-oriented design continues accepting operations and reconciles divergent state later. A system that does not tolerate partitions may preserve C and A only under the assumption that partitions do not occur, an assumption unsuitable for most networked systems.

CAP does not say that consistency and availability can never coexist. In a healthy network, a system may provide both. The trade-off becomes unavoidable when communication failure prevents nodes from knowing whether other nodes have accepted operations.

5.2 PACELC

PACELC extends CAP by asking what happens when there is no partition. The formulation is:

If Partitioned (P), choose between Availability (A) and Consistency (C); Else (E), choose between Latency (L) and Consistency (C).

PACELC highlights the normal operating cost of coordination. Even when the network is healthy, requiring a remote replica or quorum to confirm a write increases latency. A design may choose lower latency and weaker consistency, or stronger consistency and higher latency.

For example, a globally replicated shopping catalogue may prefer low read latency and tolerate slightly stale prices. A financial ledger may pay coordination costs to preserve a strict ordering of transfers. PACELC is a reasoning framework rather than a performance equation. It does not calculate latency or determine one universally correct architecture.

6. Worked Architectural Analysis

Consider an international ticketing platform. Customers search events, reserve seats, pay, and receive confirmations. Searches are read-heavy and can tolerate brief staleness. Seat allocation cannot allow two customers to purchase the same seat.

A suitable design may use a multi-tier entry point with globally distributed read replicas for event information. Search results can be cached near users. Reservation commands should be routed to an authoritative partition for the event or venue. The reservation service may use a CP-oriented protocol for seat ownership, with a short lease or expiration time. Payment processing can be integrated through a saga because payment providers and reservation storage are separate systems.

Events such as `ReservationCreated`, `PaymentAuthorized`, and `TicketIssued` can be published to an event log. Consumers update notifications, analytics, and customer history asynchronously. Each consumer must tolerate duplicate delivery. If payment succeeds but ticket issuance fails, a retry or compensating refund workflow is required.

PACELC analysis gives different answers by operation. Search prioritizes latency over immediate consistency during normal operation. Seat ownership prioritizes consistency over availability during a partition. Notifications prioritize eventual completion and may tolerate delay. This example demonstrates that architectural decisions should be made per data domain and operation, not by assigning one label to the entire application.

7. Illustrative Case: Migrating a University Examination Platform

Background

This illustrative case concerns a university whose examination platform was originally a centralized three-tier application. During examination periods, thousands of students submitted answers within narrow time windows.

Problem

The platform experienced database contention, delayed autoscaling, and service disruption when one data-centre component failed. However, examination submission required strong protection against lost or duplicated answers, while dashboards and notifications could tolerate delay.

Analysis

A complete migration to microservices would create unnecessary risk. The university first separated workloads according to consistency and scaling requirements. Submission records were assigned to partitions by examination and student identifier. The submission API was made idempotent by requiring a unique attempt identifier. A repeated request with the same identifier returned the original result rather than creating a second submission.

Approach and Solution

Stateless API instances were placed behind a load balancer. Durable submission storage used replicated partitions. An append-oriented event stream carried accepted-submission events to grading, audit, and analytics consumers. The submission path used synchronous confirmation from authoritative storage, whereas analytics processing was asynchronous. Backups were tested through restoration exercises, and replicas were distributed across failure domains.

Monitoring measured request latency, rejected submissions, replication lag, queue age, and error rates. Operational runbooks specified actions for database failover, event backlog, and suspected duplicate submissions.

Outcome

The design reduced contention by separating write-intensive submissions from read-intensive dashboards. It also made the consistency policy explicit: submission acceptance was strongly protected, while dashboards were eventually consistent. The university retained a relatively simple core rather than introducing microservices solely for fashion.

Learning Points

1. Decomposition should follow workload and consistency boundaries.

2. Idempotency is essential when clients retry after timeouts.

3. Event-driven processing is useful for secondary views but does not automatically solve transactional correctness.

4. Operational testing is part of architecture, not an afterthought.

5. A modular monolith and selective distribution may be better than a fully distributed design.

8. Professional, Governance, and Ethical Considerations

Distributed architectures spread data and authority across services, providers, and sometimes countries. Data residency, privacy, retention, access control, and auditability must therefore be designed explicitly. Replication may place personal data in jurisdictions with different legal requirements. Event logs can preserve sensitive information long after an operational database deletes it.

Organizations should define ownership for data, interfaces, incident response, and architectural exceptions. Service autonomy without accountability can create security gaps. Least privilege, encryption in transit and at rest, key rotation, secure software supply chains, and tamper-evident audit trails are standard safeguards.

Automated systems may affect access to education, finance, health, or employment. Designers should assess failure consequences, provide appropriate human oversight, and ensure that degraded modes do not unfairly disadvantage users with poor connectivity or older devices. Artificial intelligence services introduce additional concerns, including model-version consistency, data provenance, privacy, prompt injection, and the reproducibility of decisions. AI should be treated as another distributed dependency whose availability, latency, and failure behaviour must be modelled.

9. Contemporary Developments and Best Practices

Current distributed systems increasingly combine cloud regions, edge computing, containers, managed services, event platforms, and specialized accelerators. Edge deployment reduces user latency but increases heterogeneity, intermittent connectivity, and fleet-management complexity. Confidential computing and hardware-backed identity can strengthen trust across administrative boundaries. Service meshes provide traffic policy and telemetry, but they also add another control plane and should not conceal poor service boundaries.

Recommended practices include:

• Begin with domain boundaries and explicit data ownership.
• Choose consistency per operation rather than per marketing label.
• Design retries with idempotency keys and bounded backoff.
• Set timeouts for every remote call and avoid unbounded waiting.
• Use circuit breakers carefully; fail fast when dependencies are unhealthy.
• Prefer asynchronous processing where immediate response is unnecessary.
• Version APIs and event schemas compatibly.
• Measure latency, error rate, saturation, queue age, and replication lag.
• Test partitions, delayed messages, duplicate delivery, clock skew, and regional failure.
• Document recovery objectives and practise restoration.
• Minimize cross-service transactions and use sagas only with explicit compensation.
• Evaluate total cost, skills, governance, and operational maturity before adopting microservices or serverless platforms.

Challenges and Limitations

No architectural style removes distributed-systems complexity; it relocates it. Centralized systems simplify coordination but concentrate failure and scaling risk. P2P and decentralized systems distribute control but complicate trust and governance. Microservices improve independent evolution but make correctness, testing, and observability harder. Event-driven systems reduce direct coupling but introduce temporal uncertainty. Serverless reduces infrastructure management but increases provider dependence and can obscure resource behaviour.

Models are abstractions. CAP does not capture every business requirement, and PACELC does not replace measurement. A failure model that excludes correlated failures may produce false confidence. Similarly, a design that is correct under crash failures may be unsafe under malicious or Byzantine behaviour. Architectural claims should therefore state assumptions clearly and be validated through experiments and operational evidence.

Chapter Summary

Distributed architecture divides responsibilities among networked components and must be evaluated together with deployment, interaction, and failure assumptions. Client–server and multi-tier systems offer conceptual simplicity; SOA supports enterprise integration; microservices emphasize independent deployment; P2P and decentralized architectures distribute control; event-driven systems provide temporal decoupling; and serverless changes the operational boundary rather than eliminating servers.

Physical models describe deployment and correlated failures. Architectural models describe components, roles, interfaces, and ownership. Interaction models distinguish synchronous and asynchronous communication and clarify safety and liveness. Failure models specify crash, omission, timing, partition, and Byzantine assumptions.

Replication improves resilience but requires consistency decisions. Partitioning improves scale but creates routing and hotspot concerns. CAP explains the unavoidable consistency–availability choice during partitions, while PACELC emphasizes the normal-case latency cost of coordination. Effective designs make these choices per operation, use idempotency and observability, test failure modes, and align technical decisions with governance, ethics, cost, and organizational capability.

Key Terms

Distributed system: A system whose cooperating components execute on networked computers.

Client–server: An architecture in which clients request services from servers.

Multi-tier architecture: A design separating presentation, business, and data responsibilities.

Peer-to-peer: An architecture in which nodes can both request and provide resources.

Service-oriented architecture: Enterprise-oriented decomposition into contract-based services.

Microservices: Independently deployable services organized around business capabilities.

Event-driven architecture: A design in which components react to published events.

Serverless: A provider-managed execution model that hides most server administration.

Decentralization: Distribution of control or authority among independent participants.

Replication: Maintaining multiple copies of data or computation.

Partitioning: Dividing data or workload among nodes.

Consistency: The rules governing how state updates become visible.

Availability: The ability to respond successfully to requests.

Network partition: A communication failure separating functioning groups of nodes.

Idempotency: The property that repeating an operation has the same intended effect as performing it once.

Safety: The guarantee that an undesirable condition does not occur.

Liveness: The guarantee that a desirable action eventually occurs.

CAP theorem: The result that partitioned systems cannot guarantee both strong consistency and availability.

PACELC: A framework contrasting availability and consistency during partitions with latency and consistency otherwise.

Quorum: A sufficient subset of replicas whose participation supports a protocol decision.

Review Questions

Short Answer Questions

1. What distinguishes a multi-tier architecture from a client–server architecture?

2. Define idempotency and explain why it is important for retries.

3. What is the difference between a physical model and an architectural model?

4. State the CAP trade-off in the presence of a network partition.

5. Why can event-driven systems be eventually consistent?

Long Answer Questions

1. Compare SOA and microservices in terms of service granularity, governance, deployment, and operational complexity.

2. Explain synchronous and asynchronous interaction models, including their effects on latency, coupling, and failure handling.

3. Discuss the benefits and limitations of peer-to-peer and decentralized architectures.

4. Explain replication, partitioning, and coordination, and show how they influence scalability and consistency.

5. Describe PACELC reasoning and apply it to a globally distributed financial or retail system.

Analytical / Application Questions

1. Design an architecture for a food-delivery platform. Identify which operations require strong consistency and which may be eventually consistent, and justify the choices using CAP and PACELC.

2. A service receives a timeout after submitting a payment request, but the provider may have processed it. Propose a safe interaction and recovery design.

3. An organization proposes converting a modular monolith into 40 microservices. Analyse the technical and organizational risks and define criteria for deciding whether the migration is justified.

Multiple Choice Questions with Answers

Question 1

Which architecture allows nodes to act as both clients and servers?

A. Multi-tier

B. Peer-to-peer

C. Serverless

D. Three-tier client–server

Correct Answer: B. Peer-to-peer

Question 2

In an event-driven system, an event primarily represents:

A. A request for an unknown action

B. A database connection

C. A fact that has occurred

D. A server hardware failure only

Correct Answer: C. A fact that has occurred

Question 3

Which property means that repeating an operation does not create an additional unintended effect?

A. Elasticity

B. Idempotency

C. Partition tolerance

D. Decentralization

Correct Answer: B. Idempotency

Question 4

During a network partition, CAP states that a system cannot guarantee both:

A. Scalability and security

B. Latency and throughput

C. Consistency and availability

D. Replication and partitioning

Correct Answer: C. Consistency and availability

Question 5

In PACELC, the ‘ELC’ part addresses the choice between:

A. Elasticity and load capacity

B. Latency and consistency when there is no partition

C. Encryption and logging during a crash

D. Events and leases during coordination

Correct Answer: B. Latency and consistency when there is no partition

Question 6

Which failure involves a process behaving arbitrarily or maliciously?

A. Crash failure

B. Omission failure

C. Timing failure

D. Byzantine failure

Correct Answer: D. Byzantine failure

Question 7

What is a major advantage of asynchronous communication?

A. It guarantees strong consistency

B. It removes the need for retries

C. It can provide temporal decoupling between sender and receiver

D. It eliminates network failures

Correct Answer: C. It can provide temporal decoupling between sender and receiver

Question 8

A service that owns its data and can be deployed independently is most closely associated with:

A. Microservices

B. A single centralized database tier

C. A physical network model

D. A crash detector

Correct Answer: A. Microservices

Question 9

Which statement about CAP is correct?

A. It says consistency and availability can never coexist

B. It applies specifically to the trade-off during network partitions

C. It guarantees low latency for AP systems

D. It eliminates the need for replication

Correct Answer: B. It applies specifically to the trade-off during network partitions

Question 10

Why are distributed systems commonly tested with duplicate messages?

A. Messages are always duplicated by TCP

B. Retries and redelivery can cause the same message to be processed more than once

C. Duplicates prove that a system is decentralized

D. Duplicate messages reduce storage requirements

Correct Answer: B. Retries and redelivery can cause the same message to be processed more than once