1.

Write the following design patterns in the format discussed in the class:
a. Peer to Peer

Description:
Peer-to-peer systems are distributed systems in which all nodes, sometimes referred to as
peers, have identical roles and responsibilities and are capable of functioning as both clients
and servers. The peers rely on self-organization, discovery, and coordination mechanisms to
function; there is no central authority or coordinator in the system. Peer-to-peer networks are
useful for a variety of tasks, including decentralised apps, content delivery, file sharing, and
collaborative computing.

Example:
Peer-to-peer applications are prevalent in a wide range of cloud computing situations and
areas. For instance, blockchain is a distributed ledger, similar to Bitcoin, Ethereum, and
Hyperledger, that uses encryption and consensus techniques to securely record transactions
and data. Content delivery networks, or CDNs, use caching and replication techniques like
BitTorrent, IPFS, and Storj to distribute content to users based on their location and
preferences. Using synchronisation and coordination tools like Google Docs, PeerPad, and
CRDTs, collaborative computing enables users to collaborate on shared activities and data.
Through smart contracts and peer-to-peer protocols like Uniswap, Brave, and OpenBazaar,
decentralised applications (DApps) execute programmes independently of a central server or
authority.

When used:
• A peer-to-peer network is one in which every computer connected to it has an equal
share of privileges and data processing duties.
• Peer-to-peer networks, which typically accommodate up to ten computers, are helpful
in small settings.
• Each computer is given specific permissions for resource sharing, however this can
cause issues if the machine containing the resource goes down.
• Peer-to-peer networks lack a dedicated server.

Advantages:
Scalability is a primary advantage of the peer-to-peer architecture. The system can manage a
high number of peers and requests without compromising availability or performance since it
is not dependent on a single point of failure. Resilience is an additional advantage. Individual
peer failures and disruptions are tolerated by the system as long as there are sufficient peers
to preserve functioning and data integrity. The third advantage is affordability. By utilising
the peers' resources and bandwidth, the system can eliminate the need for costly, centralised
infrastructure and services.

Disadvantages:
Security is one of the primary issues with utilising the peer-to-peer design. The system is
susceptible to malicious assaults including denial-of-service, spoofing, poisoning, and
censorship because it is open and decentralised. Peer accountability and trust are also lacking
in the system, which encourages collusion and free-riding. Complexity is a further
disadvantage. To handle problems like peer discovery, coordination, synchronisation,
replication, consistency, and fault tolerance, the system needs complex algorithms and
protocols. The calibre of services is a third disadvantage. Depending on their resources,
dependability, and behaviour, peers' performance and availability might vary and be
unpredictable, which can cause problems for the system.

b. Service Oriented Architecture

Description:
Service provider, service broker, service registry, service repository, and service
requester/consumer are the three roles found in each of the building blocks of the service-
oriented architecture.

Together with the service registry, the service provider discusses the hows and whys of the
services being provided, including security, availability, pricing, and other issues. The service
category and the necessity of any business agreements are also determined by this position.

Those who want the service can obtain information about it from the service broker. Whoever
implements the broker determines its scope.

After finding entries in the broker registry, the service requester links those entries to the
service provider. Depending on the service requester's capabilities, they can be able to access
several services or not.

Example:
The Simple Object Access Protocol, or SOAP, is an exmaple of a web service standard. To
put it simply, SOAP is a messaging protocol specification used in computer networks to
exchange structured data when web services are implemented. While SOAP was initially met
with resistance, since 2003 it has grown in acceptance and appeal, becoming increasingly
commonly utilised. REST, COBRA, or Jini are other choices for putting Service-Oriented
Architecture into practice.
The ability of architectures to "operate independently of specific technologies" is crucial
since it allows for a range of implementations, including messaging systems like ActiveMQ,
Apache Thrift, and SORCER.

When used:
Standardised service agreement: Defined by one or more documents outlining the services to
be provided.
Loose coupling: Services have connections that minimise reliance on one another and are
built as independent parts.
Abstraction: Service agreements and description papers provide a comprehensive definition
of a service. Their implementation encapsulates their logic, which they conceal.
Reusability: Because services are designed as components, they may be reused more
successfully, cutting down on both the time and expense of development.
Autonomy: Services are in charge of the logic they contain, and they don't need to be
transparent about how they're implemented to service consumers.
Discoverability: Services are characterised by description documents, which are additional
metadata that helps find them efficiently. Using third-party resources effectively is made
possible via service discovery.
Composability: Complex and sophisticated operations can be accomplished by using services
as building blocks. Service choreography and orchestration offer a strong foundation for
creating services and accomplishing organisational objectives.

Advantages:
Reusable services: In Service-Oriented Architecture (SOA), apps are built using pre-existing
services. As a result, services can be combined to create a variety of uses.
Simple maintenance: Since services don't depend on one another, it's easy to update and
change one without affecting the others.
Independent of platform: Service-oriented architecture (SOA) enables the creation of
sophisticated applications by integrating services selected from many sources.
Availability: Upon request, SOA facilities are readily available to anybody.
Reliability: Because small services are easier to debug than large codes, SOA applications are
more dependable.
Scalability is enhanced by the fact that services can operate on several servers in a given
environment.

Disadvantages:
High overhead: Every time services communicate, their input parameters are validated, which
slows down performance by increasing load and response time.

High investment: SOA requires a substantial upfront investment.

Complex service management: Services communicate with one another by exchanging tasks
and messages. There could be millions of messages. Managing a big number of
communications becomes a laborious chore.

c. Publisher Subscriber Pattern

Description:
An architectural design pattern called pub/sub, also known as publish/subscribe, is used in
distributed systems to enable asynchronous communication between various services or
components. Publish/Subscribe is more adaptable and scalable even if it is built on older
design principles like event brokers and message queuing. The secret to this is that Pub/Sub
allows messages to be transferred across various system components without the components
knowing who the other is (they are decoupled).
The need to increase the size of information systems led to the development of the Pub/Sub
pattern. Most systems were scaled statically in the pre-Internet era and even in the early days
of the Internet. However, as web-based apps and the Internet grew, systems had to grow
dynamically due to the widespread use of mobile and IoT devices.
The Pub/Sub pattern is a suitable choice for controlling the design of dynamically scalable
systems because of its decoupled nature. Scale can be managed with Pub/Sub without
overwhelming system components' programme logic.

Example:
When used:
When an application needs to communicate with one or more independently developed
applications or services, which may use different platforms, programming languages, and
communication protocols, or when it needs to broadcast information to a sizable number of
users, use this pattern.

• Users don't have to respond in real time to an application that sends them information.
• The systems that are being integrated are made to accommodate a data consistency
paradigm in the future.
•Information must be distributed by an application to a number of recipients, each of whom
may have different availability needs or uptime schedules than the sender.
Advantages:
Among the many advantages of the Pub/Sub pattern are the following:
• Loose connectivity between components, which increases the modularity and
flexibility of your system.
• Great scalability (any number of publishers can theoretically communicate with
any number of subscribers via Pub/Sub).
• Pub/Sub is protocol- and language-agnostic, making it simple and quick to
implement into your IT stack.
• Event-driven, asynchronous communication that works well for low-latency, real-
time applications.

Disadvantages:
The rigidity of the information provided by the publication
The messages communicated between publishers and subscribers might have a high degree of
semantic coupling introduced by the publish/subscribe method. This implies that once the
data format of these messages has been defined, it may be challenging to change. If the
subscribers are external, it may be difficult or impossible to update them all to accept the new
format in order to modify the messages' format. Versioned APIs often have issues like these.
The drawback of this strategy is that it might be time-consuming for developers to handle
various versions.

Unpredictability in Delivery
Determining the health of subscribers might be a challenge when using the publish/subscribe
strategy.
There may be issues since the publisher is not fully aware of the systems that are receiving
the messages.
Logging systems, for instance, frequently employ the publish/subscribe paradigm. Important
messages may be missed by a logger that has subscribed to the "Critical" message type if it
crashes or becomes stuck in an error state. That way, services that depend on error warnings
won't be informed of publisher problems.
This issue can arise in any client/server system and is not specific to the publish/subscribe
approach. Nevertheless, one benefit of pub/sub is that it enables high degrees of redundancy
by enabling the simultaneous operation of several logger instances with little additional
system overhead.
Modifications to the design, including mandating receipts for communications received,
could be put into place to lessen this danger.
This would enable the publisher to get information about the subscribers' status.

2. Aren’t Publishers providing services to Subscribers? If Yes, how is it different from

SOA?

Yes, publishers provide subscribers services.

There are certain parallels between the Publisher-Subscriber relationship and Service-
Oriented Architecture (SOA). But there are significant variations in terms of goal, reach, and
technical execution:
Scope:
• Publishers and Subscribers: This is a business-to-business partnership that emphasises
community involvement and content distribution.
• Service-oriented architecture (SOA): This architectural approach emphasises service
reusability and modularity in software programmes.

Goal:
• Publishers and Subscribers: The main goals are to make material accessible and to create
communities centred around common interests.
• Service-oriented architecture (SOA): By dividing applications into separate services, SOA
aims to increase the efficiency, maintainability, and scalability of software development.

Technical Execution:
• Publishers and Subscribers: Websites, apps, communication channels, and subscription
platforms are used to implement this relationship.
• Service-oriented architecture (SOA): This architecture uses message brokers, web services,
APIs, and other technical tools for orchestrating and communicating services.

d. Shared data pattern

Description:
A shared data architecture's fundamental qualities are:
Dispersed. in order to avoid requiring any one member to possess superhuman knowledge or
vision.
In real time. Modifications will be continuously communicated and made known to other
authorised participants.
Dependable. The "single source of truth" ought to be the data. That is, the outcome ought to
be the same regardless of who views the data.
Edged. For excellent traceability, data change logs with the whole history of who altered
what and when are available.
Restricted access. Participants are limited to accessing the info they actually require.

A shared data architecture does not have to have all of them; nonetheless, the more fully each
characteristic is developed, the more advanced the shared data architecture will be.
Teams usually consider these qualities during the requirements, gathering, and design phases
of developing a solution. Let's say a team is in dire need of updates to be sent to other
applications as soon as they are made. Web sockets, database change data capture (CDC), or
even a streaming solution like Kafka—where users are always watching for update events—
can be used to achieve that. The problem with these point-to-point solutions is that there isn't
a single source of truth that can be used by several parties, especially in situations where
multiple writers can provide data at the same time.

Distributed platforms, such as Vendia Share, disrupt the traditional notion of point-to-point
solutions by guaranteeing that all participants have access to the most recent version of the
data without being dependent on a centralised platform.

Example:

Enterprise Access Management System:

Data Warehouse Example
Examples of Use: Applications for collaborative editing that let several people edit the same
document at once.

• Caching data in memory to enhance performance.

• Data on configuration sharing for dispersed systems.

When used:
This pattern is especially helpful when a lot of data is needed by several components. The
main means of communication in shared-data systems is data and the data source. In contrast,
event-based systems use message forwarding or procedure calls to facilitate communication
between its constituent parts.

Advantages:
• Loose Coupling: Producers and consumers are capable of separate evolution
without causing mutual collapse.
• Centralised Consistency: guarantees that all users see the same data.
• Simplified Testing: Individual consumers may be examined separately.
• One-to-Many Communication: Data sharing between a producer and several
consumers is simple.

Disadvantages:
• It's possible that the shared data store is a performance bottleneck.
• One potential single point of failure is the shared data storage.
• Data producers and consumers could be closely related.
3. Multiple Subscribers are using common set of Publishers. How is it different from
Shared Data Pattern?

Multiple Subscribers with Common Publishers:

• Concept: In this pattern, data is independently produced by several publishers, and it

is of interest to several subscribers for processing and receipt. By acting as a
middleman, a message broker or event bus enables subscribers to receive data without
knowing the precise identities of publishers and publishers to publish data without
knowing those subscribers' identities. This disconnection permits:
o Scalability: New publishers and subscribers can be added to the system with
ease and without disrupting already-existing components.
o Flexibility: Subscribers can select the themes they are interested in, and
publishers can publish to a variety of topics.
• Use cases: Real-time updates in social media feeds, stock tickers, and news apps.
o Asynchronous communication in systems that are distributed.
o Event-driven architectures, in which related actions in various system
components are triggered by events in one area.

Shared Data Pattern:

• Concept: This pattern allows several components to access and change a common
piece of data directly. Different techniques, such as distributed file systems,
databases, and shared memory, can be used to do this.
• Examples of Use: Applications for collaborative editing that let several people edit
the same document at once.
o Caching data in memory to enhance performance.
o Data on configuration sharing for dispersed systems.

Key Differences:
 Feature Multiple Subscribers with Shared Data Pattern
Common Publishers
Communication Asynchronous, decoupled Synchronous, coupled
Model through a message broker through direct access
Scalability Highly scalable; new Moderately scalable;
publishers/subscribers can be potential bottlenecks with
added easily large numbers of
components
Flexibility Supports filtering and selective No inherent filtering; all
subscriptions components see all data
Consistency Requires careful design to ensure Can be complex,
Management consistency across multiple especially with concurrent
readers/writers modifications
Use Cases Real-time updates, event-driven Collaborative editing,
architectures caching, shared
configuration

Selecting the Best Pattern:

The best pattern will rely on your unique needs.

• For real-time updates or event-driven communication, utilise the Multiple Subscribers

with Common Publishers paradigm if you need decoupling, scalability, and
flexibility.
• Use the Shared Data Pattern if you require close integration and real-time cooperation
on shared data.