Architecture Design of Blockchain-Based

Applications
Maximilian Wöhrer, Uwe Zdun Stefanie Rinderle-Ma
University of Vienna, Faculty of Computer Science Technical University of Munich, Department of Informatics
Vienna, Austria Munich, Germany
{maximilian.woehrer,uwe.zdun}@univie.ac.at stefanie.rinderle-ma@tum.de

Abstract—Integrating blockchain into software solutions is not In order to concretize the research objectives, we ask the
straightforward as it requires sophisticated architectural design following research questions: RQ1) Which existing architec-
to connect and orchestrate centralized elements, such as backend tural software design principles and concepts are suitable for
logic, with decentralized elements, such as blockchain ledgers and
smart contracts. We systematically explore this design space and blockchain-based applications and how can they be applied?
possible architectural solution approaches. More specifically, we RQ2) Which conceptual components in terms of architec-
provide architectural blue prints for applications with different tural design exist and how are they related? For illustra-
degrees of decentralization, describe conceptional components as tive purposes, this paper primarily refers to permissionless
well as possible relations between them. blockchains, in particular Ethereum, today’s most popular
Our research shows that an event-driven architecture incorpo-
rating a messaging framework, tethered to dedicated components ecosystem. Please note that some concepts presented have a
for handling blockchain state-changing and state-collecting oper- different valence in the context of permissioned blockchains
ations, is a prevalent approach for choreographing blockchain- (e.g., data confidentiality), but still remain applicable.
dependent business logic in blockchain-based applications. The paper is structured as follows: First, we discuss related
Index Terms—blockchain, software architecture, decentralized
work in Section II and our research methodology in Section
application, DApp, smart contract, design pattern
III. Then, we elaborate the architectural design of blockchain-
I. I NTRODUCTION based solutions as main contribution in Section IV. Finally, we
A blockchain is a distributed and decentralized ledger that discuss findings in Section V and conclusions in Section VI.
contains connected blocks of transactions [1] and can be II. R ELATED W ORK
thought of as a cryptographically secure transactional singleton
machine with shared-state [2]. The technology allows the Blockchain-Oriented Software Engineering (BOSE) is dedi-
implementation of new software architectures for decentral- cated to defining and applying software engineering principles
ized record-keeping and computation without relying on a and practices for blockchain-based system design, develop-
(traditional) central point of trust. This aspect is beneficial in ment, and deployment. Porru et al. [4] present one of the first
many cross-organizational processes [3] and efforts are being works to identify issues, challenges, and peculiarities in this
made to integrate the technology into enterprise applications. field. They advocate the need for new research directions and
However, the acceptance and adoption of the technology in novel specialized blockchain software engineering practices.
practical applications is still at an early stage. Accordingly, Wessling et al. [6] argue that a blockchain-oriented view is
there is a lack of established design principles and design required for the architectural design process and propose the
approaches that drive the integration of the technology into idea of blockchain tactics as a means to support the process
applications [4]. To address this gap, we follow up on previous of integrating decentralized elements in software architecture.
research [5] that presents a general overview of architectural In this work, however, the authors focus on the effects of
design decisions. In this context, we now turn to more detailed design patterns at the implementation level and do not provide
decision options as well as typical component structures, architectural guidance. Marchesi, Marchesi, and Tonelli [7] [8]
which we derive from existing architectural design solutions propose a holistic agile software development process for gath-
using grounded theory (GT) techniques to extract and identify ering and analyzing requirements and designing, developing,
common practices. If one considers the blockchain as a part testing, and deploying blockchain applications. Nonetheless,
of a larger system, it can be assumed that certain practices the approach is not specific enough to derive decisions on the
and architectures occur more frequently and thus prove to be architectural level. Udokwu, Anyanka, and Norta [9] explore
more advantageous than others. Furthermore, we investigate and evaluate several high-level design approaches for devel-
existing, well-proven software design concepts and assess their oping blockchain-based applications, including the former two
applicability to blockchain-based applications. works. They propose another model-driven design framework
with an automatic architecture model derivation, which lacks
a detailed description. Bodkhe et al. [10] present various
978-1-6654-3924-4/21/$31.00 ©2021 IEEE blockchain-based solutions and their applicability in various
Industry 4.0-based applications. In the aforesaid work, a in Table I Last, we discuss relevant topics in context such as
blockchain-based reference architecture is described, but rather microservices and Blockchain as a Service (BaaS).
on a high level. Viswanathan, Dasgupta, and Govindaswamy
[11] present a Blockchain Solution Reference Architecture A. Event-driven Architecture
(BSRA) that guides architects in creating end-to-end solutions As a software component, the blockchain has an asyn-
based on Hyperledger Fabric. Architectural components are chronous and event-driven character. This is due to the latency
mentioned, but only described within a layered structure, so in the execution and confirmation of transactions and the
that the interaction of the components is not apparent. fact that significant changes or operations that occur on the
So far, works that provide systematic architectural guidance blockchain are usually propagated as events. Examples are
in the field of BOSE are scarce. It is the goal of our work to events resulting from the execution of a smart contract or
remedy this shortcoming. the creation of a new block. Given these characteristics,
blockchains are not suited for real-time based systems and
III. R ESEARCH S TUDY D ESIGN likewise scenarios where end-users expect an immediate im-
In the search for (best) practices (hereinafter conceptually pact of an operation. As with other systems that do not
equivalent to software design patterns and other similar best rely on synchronous communication (i.e., no strict arrival
practices), we apply a research methodology that is guided by times of messages or signals), message coordination can be
the pattern derivation approach of Riehle, Harutyunyan, and achieved by using event-driven architecture (EDA). Event-
Barcomb [12]. The approach describes the application of es- driven architecture is an architectural style in which there is no
tablished scientific research methods for the purpose of pattern centralized controller to manage a workflow. Instead, different
discovery and validation. In accordance with this approach components interact with each other much more dynamically
patterns are discovered (“mined”) and codified (“written”) when certain events that affect their respective domains occur.
using Grounded Theory (GT) [13], [14] techniques. Driven 1) Event Sourcing: Event sourcing is a persistence concept
by our research questions and known practices from our own used in event-driven architectures. It refers to storing appli-
experience, we defined initial search terms that were used to cation state as a sequence of immutable events. With it, a
query major search engines (e.g., Google, Bing) in order to complete replay of the events that have happened since the
compile a number of well-fitting, technically detailed sources beginning of the event recording can be achieved. This con-
from the so-called “gray” literature [15] (e.g., practitioner trasts the traditional create, read, update, and delete (CRUD)
reports, practitioner blogs, system documentation etc.). The approach, where only the current state of an object is stored
resulting sources pool [16] was then examined in a later and iteratively mutated. Event sourcing has several benefits.
analysis with GT techniques. This included a thorough study It allows for the creation of any number of user-defined
and the annotation of the materials with labels (“codes” data stores as materialized views of persisted events and
established with so-called “open coding”) along with optional knowledge about the state of domain objects at any given
memos explaining important aspects of codes. Further, concep- time by examining retroactive events. Blockchain and event
tual relations between codes (so-called “axial coding”) were sourcing share characteristics which suggest a natural affinity.
established to identify candidate categories for patterns. While Both share the concept of an “immutable append only log”
this may indicate a simple linear execution of the work, pattern which is considered as the single source of truth containing all
discovery and validation proceeded incrementally in several events that have happened. Therefore, it seems natural to map,
iterative stages, in which new sources (inspired from previous combine, and extend blockchains by event sourcing within
iterations) were exploited to constantly compare, revise, and application scenarios. In this sense, during our research we
contrast patterns until a theoretical saturation was reached. encountered use cases where blockchain was used as a trustless
Theoretical saturation [13], [14] refers to a state in which event store (e.g., [17]), and vice versa, where blockchain
adding new sources no longer yields new findings, and is transactions were stored in a traditional event store (e.g., [18]).
commonly used as a stop criterion in GT-based studies. 2) Command-Query Responsibility Segregation: The
Command-Query Responsibility Segregation (CQRS)
IV. A RCHITECTURE D ESIGN OF B LOCKCHAIN -BASED pattern [19] is quite often mentioned alongside with event
A PPLICATIONS sourcing, because when using event sourcing some form of
Today, the design and development of applications based CQRS emerges almost naturally. CQRS is a design solution
on blockchain technologies is a difficult undertaking and the that segregates operations that read data from operations
degree to which the technology is used is also significantly in- that write data by using separate interfaces and persistence
fluenced by characteristics such as performance, usability, and models. This approach promotes separation of concerns, as
user experience. A well thought-out architectural design helps the distinction between write and read aspects can result
to balance these criteria. To this end, this section discusses in persistence models that are more aligned, maintainable,
design guidance for blockchain integration that we found and and flexible. Most of the complex business logic can go
coded in our study. Architectural design options including into the write model, while the read model can be kept
practices/patterns, along with typical conceptual components relatively simple. Further, problems such as scaling read
and their relationships, are discussed and finally summarized and write operations, using optimized data schemata, and
securing authorized writes are easier to solve. The pattern C. Relevance of the Backend
can be utilized for blockchain integration (see [17], [20]), for
Blockchain is a closed ecosystem, thus smart contracts
example to account for the general discrepancy of write and
cannot directly interact with off-chain services to fetch infor-
read operations. The write model is represented by executing
mation or trigger actions. On the contrary, they depend on the
transactions and storing information on the blockchain ledger.
outside world to push information into the network or trigger
The read model, on the other hand, is a locally synchronized
actions by monitoring the network. This means a backend
replica or materialized view of the blockchain to achieve fast
server is needed whenever a reliance on third-party services
read performance and rich querying capabilities.
exists, such as ingesting external data, or performing mundane
B. General Application Architectures operations like sending emails. Another use for a backend is
Blockchain can be used as a standalone platform to im- to act as cache or indexing engine for the blockchain, which
plement the entire application logic (based on smart con- also helps to provide a more responsive user interface and
tracts), or as an auxiliary tool in larger enterprise solutions. smoother perceived user experience. While the ultimate source
Figure 1 illustrates this aspect and contrasts a traditional 3- of truth is the blockchain, clients can rely on the backend
tier application design with the main decentralization styles, for search functions and validate the returned data on-chain.
namely a fully decentralized and a hybrid blockchain-driven Next, large data storage is impractical on the blockchain due
architecture, discussed below. to the high costs associated with on-chain storage. Therefore,
1) Fully Decentralized Applications: A decentralized ap- an application may need to rely on a backend to store large
plication (DApp) is a software solution that builds on a amounts of data, while only a hash is stored on the blockchain
distributed computing platform. A DApp typically consists for validation. In the same way, complex calculations that
of a Web frontend that issues direct calls to a decentralized would exceed the block gas limit of the blockchain can be
backend infrastructure (i.e., the blockchain executing smart moved to a backend. Another case where a backend can
contracts incorporating the entire application logic). This be useful is batching multiple transactions. The user can be
structure resembles a two-tier client-server architecture, with relieved of repetitive transactions that take a lot of time by
no intermediate support required for operation. The front- collecting user signed transactions in the backend and issuing
end code, which can be written in any language, can be them all at once. As long as these transactions are not time
hosted on a central server or on a decentralized storage (e.g., sensitive, batching them is a valid use case. A backend is also
IPFS). Through the latter a complete decentralization of the handy for automation, when a smart contract is designed to
application is achieved. be called at a future time. Since smart contracts are passive
2) Hybrid (Semi-Decentralized) Applications: Building entities, i.e. they do nothing until a participant explicitly
fully decentralized applications based solely on distributed interacts with them, there is no built-in ability to schedule
components can be a difficult undertaking due to current events in smart contracts. Thus, a backend system can be used
technical limitations and usability challenges. Therefore, the to reliably initiate periodic calls for smart contracts.
current approach to building such applications is more nu-
anced. Rather than relying solely on decentralized compo- D. Conceptual Components
nents, a hybrid architecture is often implemented in which The anatomy of blockchain-based applications in terms of
centralized components are beneficially added. In this context, essential components is to some degree similar across differ-
a traditional backend is still relevant and several reasons speak ent use cases. In the following, we list several components
for its use, although it lowers the trust compared to purely that every blockchain-like solution may wish to consider in
decentralized applications. its architectural design. Commonly found layout patterns of
components are outlined using the example of a typical DApp
Traditional Web Decentralized incorporating a backend in Figure 2 and an enterprise-oriented
Application Application
application containing several loosely coupled services (e.g.,
Client Client
microservices) in Figure 3. While there are many degrees of
Application Decentralized freedom in such architecture designs, such rough blueprint
Server Storage
patterns can help in initial designs and for architecture clas-
Frontend Frontend
sification. In the following, we discuss the typical conceptual
Blockchain
Platform
components in those broader architecture patterns.
Backend Smart Contracts
1) Wallet: Instead of a password-protected centralized ac-
Hybrid
count, blockchain users have a decentralized identity that is
Application based on asymmetric encryption. The mechanism relies on
Database Ledger pairs of keys: public keys, which may be distributed openly,
and private keys, known only to the owner. A key pair is
the identity on the blockchain. The public key (in a shorter
Fig. 1. A traditional, hybrid, and decentralized application architecture. representation) serves as account identification (address) and
is derived from the private key that grants ownership of that
 Frontend Backend Blockchain Frontend Backend Blockchain 3rd Party

3 7

Identity & Access Key

Management Vault
10 10
Oracle
2 4 7
2 5 9

HTTP/REST API HTTP/REST JSON RPC

Edge Edge Message
Call
Browser Service Application Event Browser Service Bus
Blockchain Transaction Blockchain
HTML, CSS, JS Listener HTML, CSS, JS
Endpoint Manager Endpoint
Web3.js 4
6 6
11 Blockchain
8 11
1 Application
Smart Smart
Off Chain Contract Contract
Off Chain
Wallet & Storage App App Event
Storage
Private Key Listener
JSON RPC

Fig. 2. Typical component structure pattern of a DApp. Fig. 3. Typical component structure pattern of an enterprise grade blockchain integration.

account. Therefore the private key is the most crucial informa- integrating blockchain is what data and computations to put
tion for identification and its safekeeping is essential. A wallet on-chain respectively off-chain. This decision is largely influ-
is either a device, physical medium, program or service that enced by the business case and the intended benefit of using a
stores a user’s private keys. In addition to this basic purpose, blockchain (trust building, traceability, etc.) as well as current
wallets often provide the functionality of encrypting, signing, technological limitations. Generally, one should follow the
and forwarding information (transactions) to the blockchain. basic design philosophy of using blockchains sparingly as they
2) Edge Service: Edge services are components that are are slow and expensive. In terms of the communication flow
exposed to the public Internet and provide the capabilities between the application logic and the blockchain, this aspect is
required to deliver functionality and content to users over typically split into two separate components, one performing
the Internet. They can refer to a multitude of components read (section IV-D8) and the other write (section IV-D9) oper-
such as content delivery networks (CDNs), firewalls, load ations. These components then serve as an interface to interact
balancers, API gateways, reverse proxies, etc. They typically with the blockchain. When following a service-based design,
allow a shielded data flow from the Internet into the provider’s it is also possible to further encapsulate both components
infrastructure and into the enterprise. Edge services can also through a dedicated “blockchain service” to have a central hub
support backend applications by performing common tasks for blockchain interaction (e.g., Hyperledger Fabric Gateway).
such as authentication, authorization, logging or monitoring. 5) Message Bus: In a service-oriented application, the
3) Identity and Access Management: The identity and services not only process requests from users, but interact
access management component stores user information to sup- with each other to handle these requests. Therefore, they
port user authentication and authorization as well as the pro- must engage in an appropriate communication protocol. In
vision of user data. Edge services can use this to control user- such a situation, asynchronous communication by exchanging
specific access to resources, services, and applications. For messages via a message framework has many advantages.
blockchain-based applications, it is necessary to align identity The messaging framework takes the role of a message broker
and access management holistically also with the blockchain allowing to validate, store (buffer), transform, and route (one-
inherent identity concept. It needs to be clarified to what extent to-one/many, content/topic-based) messages between services.
users need sovereignty over their own blockchain identity and This approach offers the advantage of loose runtime cou-
how this maps into an application-wide identity management pling, because it decouples the message sender from the
perspective. For example, it is possible to leave the blockchain consumer. It also improves availability, given that the message
identity handling to the user or to the application as a custodian framework buffers messages when a consumer is temporarily
responsibility; in addition, an application-tailored blockchain unavailable. However, this aspect also reveals a disadvantage,
identity concept without user binding is also conceivable. All namely that the message framework must be highly available.
of this must also be reconciled with transaction handling and Looking at our gray literature sources, the choice for a messag-
secret key custody. In this context, it is possible to handle key ing framework basically comes down to message processing
management and transaction submission either entirely by the or stream processing. In message processing, messages are
user or in the backend, or as a middle ground have meta- written to a queue and a broker takes care of delivering the
transactions where user-signed transaction requests are sent published messages addressed to specific endpoints. Once the
via a backend that pays for their execution. processing of a message is confirmed, the message is removed.
4) Backend Application Logic: An application implements This form of message delivery is suitable for environments
the logic required to achieve business objectives either by with complex pre-definable and stable routing logic or where
building a monolithic application, or a suite of small services there is a need for guaranteed one-to-one delivery of messages.
organized by business capabilities that can be independently Common platforms for message processing are ActiveMQ or
deployed. One of the most important considerations when RabbitMQ. In stream processing, messages are written to a
log that is persistent (limited to a retention period/size) and IPFS, Swarm) for Binary Large Objects (BLOBs), whereby
any endpoint may listen to these events and react accord- the integrity of the data is guaranteed by storing hashes on-
ingly. Messages are not removed once they are consumed, chain. All things considered, it is advisable to treat both
instead they can be replayed or consumed multiple times. This storage concepts separately, although it is technically possible
implies that the endpoints keep track of which messages to to unify them. For completeness, if data is to be held only on-
read (next). Popular stream processing platforms are Kafka chain, techniques such as ordinary encryption, homomorphic
or Pulsar. When using a streaming platform one can filter, encryption (HE), or zero-knowledge proofs (ZKPs) can be
aggregate, analyze or transform any blockchain events (e.g., used to ensure data confidentiality.
mined transactions or blocks, emitted event logs) and also 7) Key Vault: A key vault is a component used to maintain
combine this information with non-blockchain events. Hence, control of encryption keys and other secrets. It is important
one could build a streaming analytics process that performs for providing the private key in scenarios where transactions
state checks by monitoring contextually relevant events over need to be signed in the backend. There are several complex
time (e.g., [21]). To sum up, message processing is all about strategies and different software solutions that allow storing
smart pipes, dumb endpoints; while data stream processing private keys quite securely on the backend (e.g., HashiCorp
is the opposite: dumb pipes, smart endpoints. In principle, Vault). Some solutions build on geographically distributed
both messaging framework types can be used for blockchain databases, while others built on specially designed hardware.
integration, but this decision also depends on the surrounding 8) Event Listener: The event listener (e.g., Eventeum) is
application components and the integration effort regarding the a service component in the backend infrastructure and listens
software stack used. Overall, regardless of the taken approach, for and reacts to events emanating from a blockchain system.
the logic implemented in endpoints should be idempotent, so It contributes to a clear separation of concerns by avoiding
that receiving the same event twice has no side effects. the need for services to subscribe directly to a blockchain
6) Off-Chain Storage: Any data store outside the endpoint for events. It handles (dynamically) registered event
blockchain that holds data related to the blockchain can be subscriptions, and broadcasts these events in a consumable
considered as off-chain storage. Off-chain storage serves two manner (over a message bus) to downstream services run-
main purposes. On the one hand, it should enable faster access ning on the backend. Blockchain is a closed system, so for
to on-chain data through local replication, and on the other event retrieval, inevitably repeated polling against blockchain
hand, it should decouple business data from the blockchain, endpoints is required. Notably, there are two possibilities:
be it for reasons of confidentiality or data size. The former is a Either make explicit endpoint protocol requests for certain
read-only store and since it reflects the on-chain state, it should events, e.g., to check whether a transaction has been mined
only be updated according to received blockchain events and based on a transaction hash, or follow a “crawler” based
not by business logic. Its purpose is to support caching approach, where a bulk invocation retrieves all transactions
and indexing to enable search, filter, sort, and pagination at once given a (new) block number for examination. In both
capabilities for on-chain data. There are several ways to realize cases, in order to avoid undetected events, the event listener
this type of storage. For example, it is conceivable to use the has to gracefully handle various errors that invariably occur
messaging framework (e.g., Kafka) as event store and utilize in production systems: nodes out of sync, crashing nodes,
its sink connectors (with Kafka Connect) to provide data to congested nodes, network disconnects, stale data returned in
databases, key-value stores, and search indexes (e.g., [18]). requests, etc. This suggests that it is advantageous to use
For data provisioning from the blockchain, source connectors multiple (own) blockchain endpoints for redundancy. In this
exist that allow to ingest blockchain data tapped via web3 into constellation an aggregator pattern can combine (and de-
Kafka (e.g., [22]). Another approach is to create a separate data duplicate) multiple endpoint events to propagate the data in
store and synchronization service that subscribes to various a reliable, at-least-once manner. In the same way, the event
blockchain events on the message bus and pushes data to a listener may consider the immutability of the event stream
storage, which later on is consumed by application services (depending on the consensus mechanism). For a consensus
for queries. As a side note, there is also a decentralized algorithm that allows multiple chain heads, there may be
solution for querying in which a frontend database is used. multiple competing event streams at any one time. It is either
For this purpose a browser database (e.g., PouchDB, GunDB) possible to wait for guaranteed event finality (sufficient suc-
syncs all relevant events, but this approach is not suitable cinct block confirmations), or propagate events as soon as they
for applications with a high data respectively event load. arrive and assume that downstream services handle ramifica-
Now for the second purpose, namely a separate off-chain tions of prematurely published events. The latter approach has
storage to detach business data from the blockchain. This been mentioned in a few gray literature sources and adopts an
type of storage can be used by business logic for a more eventual consistency guided way of thinking for transactions,
controlled management of confidential data and may also whereby the application assumes that any blockchain transac-
serve as an exchange channel, if a shared storage is used. tion being waited on, will eventually confirm and continues
Its realization can take many forms depending on the type on as usual. This approach leaves the application in a state
of data, such as a database (e.g., SQL, NoSQL) for metadata which is ahead of the blockchain, allowing for example an
or a decentralized Content-Addressable-Storage (CAS) (e.g., improved user experience. However, having two instances of
state (i.e. blockchain and application) can be problematic if dependencies required for testing. For common concerns (e.g.,
state management is not handled carefully including rollback access control) audited and production-tested library contracts
scenarios; namely, when a transaction fails. (e.g., OpenZeppelin) and standardized contract implementa-
9) Transaction Manager: The transaction manager is a tions (e.g., ERC-20) should be used. Further, it is advisable
service within the blockchain application that receives mes- to conduct peer reviews that focus on reducing excessive
sages and issues state-changing transactions (invoking smart complexity and to consult specialized smart contract auditors.
contracts). It is an abstraction that controls how transactions Due to the inherent characteristics/limitations of blockchain-
are signed and broadcast to the blockchain network, via a con- based program execution, smart contracts require a rather
nected blockchain endpoint. The component performs various unconventional programming paradigm. To handle those chal-
tasks associated with the publication of transactions. First, it lenges, various design patterns emerged. A detailed discussion
takes care of estimating adequate transaction costs, to ensure is beyond the scope of this paper, thus we refer to [23] [24].
transactions are equipped with enough funds for a timely In terms of data processing, smart contracts have their own
execution. Second, it takes care of nonce management. A state, but mostly they operate in relation to a common data
nonce is an arbitrary (mostly sequential), unique number that model within the domain of a system, thus modeling and
is used to prevent replay attacks. Third, it deals with signing handling state transfer is a main concern. Complex aggregate
the entire transaction. This step usually integrates a key vault or inferred state computations are typically kept off-chain
as a private key assembly solution. Some blockchain libraries and pushed on-chain with trusted oracles as needed. Another
(e.g., web3, ethers) embed the mentioned tasks behind the topic worth mentioning is the structural design and layout
scenes, nevertheless it is important to know the background. of smart contracts. In this context, there are different design
In addition, the transaction manager has to handle various options: A single smart contract acts as an interface (facade)
errors that may occur: nonce errors, network congestion, that orchestrates interaction with other downstream smart
dropping peers, dropping transactions due to a sudden price contracts, or multiple smart contracts act independently with
increase, etc. In order to ensure reliable and stable transaction equal priority, and their functionality is being combined within
processing, the transaction manager can join forces with the a client/backend. In certain scenarios it is also common to use
event listener to verify that transactions are mined within a a template (factory) contract on-chain to instantiate contracts
specified time. If this is not the case, a certain transaction with the same structure and flow, but for a different context.
can be republished with different parameters (e.g., corrected
nonce, a higher tx fee) and monitoring starts again. It should TABLE I
D ESIGN DECISIONS , OPTIONS , AND CONCEPTUAL COMPONENTS .
be noted that there are API gateway service providers (e.g.,
EthVigil) that offer transaction lifecycle management and also Design Decision Design Option Conceptual Component
enable blockchain monitoring via webhooks or websockets. Decentralization Full N/A
Level Partial N/A
10) Blockchain Endpoint: A blockchain endpoint is a de- Blockchain Wallet
Identity
vice or node running a piece of software that implements the Provisioning
Custodial
ID & Access Mngmt
blockchain protocol. A node verifies all transactions in each In-House
User-Tx Wallet
block, keeping the network secure and the data accurate. Typi- Transaction
Meta-Tx
Handling Transaction Manager
cally, different node types and polyglot node implementations Backend-Tx
Key User Wallet
exist (e.g., Geth, Parity). A full node has the entire blockchain Management Backend Key Vault
downloaded and available. Hence, it can verify transactions Transaction Strict Event Listener /
and execute smart contracts independently. A blockchain net- State Sync Eventual Backend App. Logic
Blockchain Own Node
work is maintained and operated by full nodes. A light node Blockchain Endpoint
Connection 3rd Party
only holds block headers and can validate transactions with Frontend Decentr. Storage N/A
Provisioning Backend Edge Service
the support of a full node. In addition, there are also service Application On-Chain Smart Contract
providers that operate node clusters (e.g., Infura, QuikNode) Logic Off-Chain Backend App. Logic
which allow users to interact with the blockchain without Component Point-to-Point (Queue)
Message Bus
Orchestration Pub/Sub (Topic)
having to set up their own node. All in all, operating an own Rich Frontend DB N/A
node requires no trust in the network since the data can be Querying Backend DB Off-Chain Storage
Confidential On-Chain (Encr., HE, ZKPs) Smart Contract
verified in the node itself. If the blockchain is to be used in a Storage Off-Chain (CAS & Hash Ref.) Off-Chain Storage
truly private, self-sufficient and trustless manner, the operation
of an own node is required.
11) Smart Contract: A smart contract implements the E. Blockchain Smart Contracts and Microservices
business logic on the blockchain and can be seen as a self Microservices are an application architectural style in which
executing autonomous entity. As a design principle, contracts a complex application is composed of many smaller, discrete,
should be focused on a single responsibility or capability decoupled, and network-connected services that communicate
(preferring many simpler smart contracts to a few larger with each other using standardized interfaces. Although smart
ones) and constructed to minimize the number/size of on- contracts and microservices are fundamentally different in
chain transactions/write operations (to reduce costs) and the terms of the native environments they serve (decentralized
vs centralized platforms) and the challenges they seek to blockchain nodes on their respective platforms, some even
address, they are both a response to the rise of distributed allow the use of third-party infrastructure. Various blockchain
architecture. While smart contracts are more about enabling ecosystems and consensus mechanisms are offered, mostly
transactions in low-trust environments, microservices are about geared towards permissioned blockchains (e.g., Hyperledger
enabling modularity and scale. However, smart contracts and Fabric, ConsenSys Quorum) that focus on performance and
microservices also have commonalities from a service-oriented speed with strict privacy and access controls, which are
architecture perspective (see [25] [26] [27]). Both are de- preferred for business collaboration. In addition, many plat-
signed for focused functionality, autonomy, composability, and forms offer a variety of different applications for opera-
communication via standardized and well-defined interfaces. tions, node, and smart contract management. Some even
Hence, smart contracts can to some extent be interpreted as offer ready-to-use templates to provide predefined blockchain
services of a blockchain-based computing paradigm. In this network configurations or generic applications (e.g., supply
light, it makes sense to combine both concepts and design chain, financial services). Pricing models vary (e.g., number
blockchain-based applications with microservices architecture of nodes/transactions, storage space required, CPU utiliza-
principles. Following this approach brings not only the benefits tion), also among providers, and often tenants can choose
associated with microservices (e.g., loose coupling, scalability, among several different options. As for the degree of built-
polyglot development, etc.) but also facilitates blockchain in blockchain integration features, these vary between ser-
integration. When blockchain is treated as a service component vice providers. Some providers allow a deep integration with
in a microservices paradigm, it becomes easier to deal with other built-in platform services out-of-the-box (e.g. through
its asynchronous and event-based nature. Proven concepts adapters, connectors, triggers, purpose fitted SDKs, etc.) using
in microservices architecture, such as EDA, event sourcing, different integration approaches (e.g., serverless functions,
and CQRS, provide useful tools in this context. With EDA workflow orchestration), while others focus on infrastructure
blockchain transactions can emanate as events and the flow of provision and basic interaction. With service providers in
information within a system can be organized asynchronously the first group, a Function-as-a-Service (FaaS) approach is
in coordination with these events. Event sourcing and CQRS feasible, allowing the use of serverless computation options
complement this approach, as blockchain state changes can based on event-driven models where a piece of code (aka
be stored as a continuum of immutable events within an event “function”) calling a smart contract is invoked by an event-
store, from which any view or structural model can be derived. based trigger such as a HTTP request (or any other event).
This enables, for example, the implementation of a uniform
F. Blockchain as a Service (BaaS) interface for smart contract interaction in a REST-API manner.
Looking at current trends in software development, one can
speak of a new cloud-native application era where IT systems V. D ISCUSSION
and applications are increasingly being outsourced to cloud While it may seem straightforward to use blockchain for
service providers, for reasons of cost savings and improved specific business scenarios, using the technology often comes
management and maintenance. This trend has also caught at the expense of scalability, privacy, and usability. As a
up with the blockchain sector under the term Blockchain result, the architectural design of blockchain-based applica-
as a Service (BaaS). BaaS enables businesses to rely on tions is currently influenced by the need to compensate for
a service provider to provision and manage aspects of a theses drawbacks. This is being achieved with a variety of
blockchain infrastructure in order to facilitate the development, approaches, all aimed at shifting responsibility to centralized
testing, deployment, and ongoing management of blockchain components in areas where blockchain is currently lacking.
applications. This approach allows development resources to This leads to hybrid architectures combining centralized and
be better focused on a specific goal by utilizing a wide range decentralized components, in which the engineering challenge
of readily available components while avoiding infrastructure is comprised of ensuring a smooth and timely communication
and platform configuration overhead. A cloud environment can between the two. In such environments, it can be advantageous
also be attractive in order to keep access and cooperation to treat events as first-class citizens of an application and use
hurdles low for other participants (e.g., in a consortium). a messaging framework to coordinate communication between
However, there are also disadvantages. Relying on a single different components in an event-driven manner. As far as
service provider to run a decentralized blockchain network can communication with the blockchain is concerned, the inter-
be contradictory as it introduces a form of (re)centralization action can be narrowed down to two aspects. First, listening
(trusting those who manage infrastructure). There is also the to blockchain events and reading the blockchain network state.
risk of a vendor lock-in, as it is difficult or very expensive Second, publishing transactions to invoke state-changing oper-
to switch to a different service provider (due to lack of ations. This is basically a two-way communication where the
standardization especially for BaaS); the same also applies to transaction manager is the write channel and the event listener
the selection of a blockchain platform. is the read channel. By applying a service-oriented paradigm
Many well-known IT companies such as Microsoft, Ama- to these components and using asynchronous communication,
zon, IBM, SAP, or Oracle now offer BaaS solutions (for a blockchain integration boils down to choreograph blockchain-
comparison see [28] [29] [30]) and enable the operation of dependent business logic with these gateway services.
 Setting up application and blockchain infrastructure com-
R EFERENCES
ponents can be a time-consuming and laborious task. Instead
of developing an in-house solution with self-managed soft- [1] M. Samaniego and R. Deters, “Blockchain as a Service for IoT,” in
ware, it can be efficient to outsource the infrastructure chal- Proc. - 2016 IEEE Int. Conf. Internet Things, 2017, pp. 433–436.
lenges to API gateway services or to cloud service providers. [2] G. Wood, “Ethereum: a secure decentralised generalised transaction
ledger,” Ethereum Proj. Yellow Pap., 2014.
While gateway services abstract and encapsulate blockchain [3] J. Mendling, I. Weber, W. Van Der Aalst, et al., “Blockchains for
interaction behind HTTP API calls, cloud service providers business process management - Challenges and opportunities,” ACM
offer a comprehensive implementation platform with a set of Trans. Manag. Inf. Syst., 2018.
[4] S. Porru, A. Pinna, M. Marchesi, et al., “Blockchain-oriented software
architectural artifacts that can be leveraged to accelerate the engineering: Challenges and new directions,” 2017 IEEE/ACM 39th
development. Various compute, orchestration, storage, mes- Int. Conf. Softw. Eng. Companion, no. February, pp. 169–171, 2017.
saging, logging, and monitoring services can be combined. [5] M. Wöhrer and U. Zdun, “Architectural Design Decisions for
Blockchain-Based Applications,” in 3rd IEEE Int. Conf. Blockchain
Service providers with built-in integration options also have Cryptocurrency, 2021.
the advantage of being able to abstract direct interactions with [6] F. Wessling, C. Ehmke, O. Meyer, et al., “Towards Blockchain Tactics:
the blockchain, facilitating the flow of communication and Building Hybrid Decentralized Software Architectures,” in 2019 IEEE
Int. Conf. Softw. Archit. Companion, IEEE, 2019, pp. 234–237.
eliminating concerns about the reliability of transaction han- [7] M. Marchesi, L. Marchesi, and R. Tonelli, “An Agile Software
dling and event notification. In addition, available integration Engineering Method to Design Blockchain Applications,” pp. 1–8,
options can offer a scaffolding, that allows to wrap blockchain 2018.
[8] L. Marchesi, M. Marchesi, and R. Tonelli, “ABCDE -Agile Block
interaction into easier consumable and integratable blockchain Chain dApp engineering,” no. December, 2019.
services (e.g., as FaaS). [9] C. Udokwu, H. Anyanka, and A. Norta, “Evaluation of Approaches
Overall, BaaS solutions can ease blockchain and application for Designing and Developing Decentralized Applications,” no. June,
pp. 1–18, 2020.
infrastructure management and speed up development, but are [10] U. Bodkhe, S. Tanwar, K. Parekh, et al., “Blockchain for Industry 4.0:
not on par with self-managed solutions in terms of provided A comprehensive review,” IEEE Access, vol. 8, pp. 79 764–79 800,
trust. Nevertheless, the degree of trust can be indirectly 2020.
[11] R. Viswanathan, D. Dasgupta, and S. Govindaswamy, “Blockchain
influenced by how much is managed by a service provider, Solution Reference Architecture (BSRA),” pp. 1–12, 2019.
respectively whether BaaS is consumed as SaaS, PaaS, or IaaS. [12] D. Riehle, N. Harutyunyan, and A. Barcomb, “Pattern Discovery and
Validation Using Scientific Research Methods,” no. February, 2020.
VI. C ONCLUSION [13] B. G. Glaser and A. L. Strauss, Discovery of grounded theory:
Strategies for qualitative research. 2017.
Blockchain is a disruptive technology for enabling mu- [14] J. M. Corbin and A. Strauss, “Grounded theory research: Procedures,
tual trust in collaborative environments and has the potential canons, and evaluative criteria,” Qual. Sociol., 1990.
to replace existing business models with new technological [15] V. Garousi, M. Felderer, M. V. Mäntylä, et al., Benefitting from the
grey literature in software engineering research, 2019.
solutions. However, to leverage the technology, new types [16] Arch. Design of BC-Based Applications - Knowledge Sources, [On-
of architectures and designs are needed. To this end, we line]. Available: https://github.com/maxwoe/bc architecture design.
have described architectural design solutions for creating [17] Transmute Framework, [Online]. Available: https : / / github . com /
transmute-industries/transmute.
blockchain-based applications with different degrees of decen- [18] Ocean Bounty: Smart Contract Event Monitoring Tool, [Online].
tralization. In this context, we studied existing solutions from Available: https://explorer.bounties.network/bounty/2146.
which we inferred typical architectural layouts and conceptual [19] C. Richardson. (2017). Microservices Patterns, [Online]. Available:
https://microservices.io/patterns/index.html.
components. Based on our findings, we identified high-level [20] Hyperledger Fabric CQRS-ES, [Online]. Available: https : / / data .
architectural blueprints or patterns in which we described key hkoscon.org/event/make-hyperledger-fabric-reactive-and-cqrs-es.
components along with their purpose and interaction. [21] Blockchain Streaming Analytics, [Online]. Available: https : / / www.
youtube.com/watch?v=rY1fEaCvwXk.
While identifying suitable business cases is key to the [22] Kafka-web3-connector, [Online]. Available: https : / / github . com /
success of using blockchains, it is equally important to build satran004/kafka-web3-connector.
solutions on a robust architecture. For the integration of [23] X. Xu, C. Pautasso, L. Zhu, et al., “A pattern collection for blockchain-
based applications,” in ACM Int. Conf. Proceeding Ser., 2018.
blockchain with its asynchronous and event-driven character, [24] M. Wöhrer and U. Zdun, “Design Patterns for Smart Contracts in the
it is natural to adopt architectural styles and programming Ethereum Ecosystem,” in 2018 IEEE Int. Conf. Internet Things, 2018,
paradigms that are focused on these very characteristics. In pp. 1513–1520.
[25] I. Weber, “Blockchain and Services – Exploring the Links: Keynote
this regard, an event-driven architecture consisting of reactive Paper,” Lect. Notes Bus. Inf. Process., vol. 367, no. October 2019,
components such as microservices or, in the cloud context, pp. 13–21, 2019.
serverless functions, and dedicated blockchain read/write gate- [26] F. Daniel and L. Guida, “A Service-Oriented Perspective on Blockchain
Smart Contracts,” IEEE Internet Comput., vol. 23, pp. 46–53, 2019.
way services provides a good fit. [27] G. Falazi, A. Lamparelli, U. Breitenbuecher, et al., Unified Integration
Although blockchain has not yet broken through as a of Smart Contracts through Service Orientation, 2020.
mainstream application foundation today, the technology holds [28] M. M. H. Onik and M. H. Miraz, “Performance Analytical Comparison
of Blockchain-as-a-Service (BaaS) Platforms,” Lect. Notes Inst. Com-
the potential to reshape business relationships once operational put. Sci. Soc. Telecommun. Eng. LNICST, vol. 285, pp. 3–18, 2019.
improvements and increased efficiencies come to fruition. [29] A. Kernahan, U. Bernskov, and R. Beck, “Blockchain out of the Box
Along the way, future research could investigate (architectural) – Where is the Blockchain in Blockchain-as-a-Service?” Proc. 54th
Hawaii Int. Conf. Syst. Sci., vol. 0, pp. 4281–4290, 2021.
standards for commonly occurring application scenarios to [30] V. Yussupov, G. Falazi, U. Breitenbücher, et al., “On the serverless
foster a quick adoption of blockchain technology. nature of blockchains and smart contracts,” arXiv, 2020.