The Open Group Guide
Edit the Document Title as appropriate.
You should also edit the Document Title in the footers. Note that there are several sections in the template, all of which should be checked. Ensure that the front matter section has Roman page numbers and that the main body begins on Page 1 (Arabic).
When circulating as a draft, the cover should contain a confidentiality marking; e.g., “The Open Group Confidential. Unapproved Draft. Subject to Change.”. It is also recommended to use a watermark with the word DRAFT.
Select the applicable boilerplate below. Edit the copyright date using the format Month Year. Enter the Document Title. The ISBN (International Standard Book Number) and Document Number will be supplied by The Open Group. Edit the email address for feedback as appropriate. The rest of the copyright text should be left unchanged.
The following copyright statement is applicable to all publications not covered by a commercial/license structure (i.e., documents that are freely available downloads to members, and those that are freely available downloads to all):
Copyright © <Year>, The Open Group
The Open Group hereby authorizes you to use this document for any purpose, PROVIDED THAT any copy of this document, or any part thereof, which you make shall retain all copyright and other proprietary notices contained herein.
This document may contain other proprietary notices and copyright information.
Nothing contained herein shall be construed as conferring by implication, estoppel, or otherwise any license or right under any patent or trademark of The Open Group or any third party. Except as expressly provided above, nothing contained herein shall be construed as conferring any license or right under any copyright of The Open Group.
Note that any product, process, or technology in this document may be the subject of other intellectual property rights reserved by The Open Group, and may not be licensed hereunder.
This document is provided “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. Some jurisdictions do not allow the exclusion of implied warranties, so the above exclusion may not apply to you.
Any publication of The Open Group may include technical inaccuracies or typographical errors. Changes may be periodically made to these publications; these changes will be incorporated in new editions of these publications. The Open Group may make improvements and/or changes in the products and/or the programs described in these publications at any time without notice.
Should any viewer of this document respond with information including feedback data, such as questions, comments, suggestions, or the like regarding the content of this document, such information shall be deemed to be non-confidential and The Open Group shall have no obligation of any kind with respect to such information and shall be free to reproduce, use, disclose, and distribute the information to others without limitation. Further, The Open Group shall be free to use any ideas, concepts, know-how, or techniques contained in such information for any purpose whatsoever including but not limited to developing, manufacturing, and marketing products incorporating such information.
If you did not obtain this copy through The Open Group, it may not be the latest version. For your convenience, the latest version of this publication may be downloaded at www.opengroup.org/library.
The following copyright statement is applicable for all other documents, except for those that require specific restrictions (which must be prepared by Legal):
Copyright © <Year>, The Open Group. All rights reserved.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright owner.
It is fair use of this specification for implementors to use the names, labels, etc. contained within the specification. The intent of publication of the specification is to encourage implementations of the specification.
This specification has not been verified for avoidance of possible third-party proprietary rights. In implementing this specification, usual procedures to ensure the respect of possible third-party intellectual property rights should be followed.
Document Number: TBA
Published by The Open Group, <Month Year>.
Comments relating to the material contained in this document may be submitted to:
The Open Group, Apex Plaza, Forbury Road, Reading, Berkshire, RG1 1AX, United Kingdom
or by electronic mail to:
The Contents are generated when printing the document. To manually update them, Right-Click on the Contents list and select Update Field.
2.2 Data responsibilities in context of MSA 6
3.1 Self Containment Revisited 8
3.2.1 Scenario #1: The MSA does not Persist Data (is Stateless) 9
3.2.2 Scenario #2: The MSA Leverages Established Tools to Handle Persistence 10
3.2.3 Scenario #3: The Microservices Provides Data Persistence Consistent with MSA Needs. 10
3.3 Data persistence in MSA solutions 10
3.3.1 Case 1: Dedicated for each Microservice instance. 10
3.3.2 Case 2: External synchronization via queues/message bus and Application instance 12
3.3.3 Case 3: External synchronization via queues/Message Bus 13
4.1 Definition of Data Consistency 16
4.3 Types of Data Consistency 17
4.6 Architecting for Consistency 19
4.7 Consistency and Storage Scenarios 20
4.7.1 Scenario 1: The MSA does not Persist Data 20
4.7.2 Scenario 2: The MSA Leverages Established Tools to Handle Persistence 20
4.7.3 Scenario 3: The Microservices Provide Data Persistence Consistent with MSA Needs 21
5 Capabilities Needed to Persist Data 23
5.3 Bulk Load Data that is sourced externally 24
5.4 Bulk Extract Data for Analytical Processing 24
6 Patterns for Data in an MSA 26
6.2 Full Data Replication Pattern 26
6.3 Overlapping Shards Data Pattern 27
6.4 Bulk Data Snapshot Export 28
9 Sample Heading at Level 1 39
9.1 Sample Heading at Level 2 39
9.1.1 Sample Heading at Level 3 39
A Sample Appendix Heading at Level 1 42
A.1 Sample Appendix Heading at Level 2 42
A.1.1 Sample Appendix Heading at Level 3 42
The Open Group is a global consortium that enables the achievement of business objectives through technology standards. Our diverse membership of more than 900 organizations includes customers, systems and solutions suppliers, tool vendors, integrators, academics, and consultants across multiple industries.
The mission of The Open Group is to drive the creation of Boundaryless Information Flow™ achieved by:
Further information on The Open Group is available at www.opengroup.org.
The Open Group publishes a wide range of technical documentation, most of which is focused on development of Standards and Guides, but which also includes white papers, technical studies, certification and testing documentation, and business titles. Full details are available at www.opengroup.org/library.
This section should include a brief introduction to the document and its purpose, the intended audience and any prerequisite knowledge, a brief overview of the document structure, and typographical conventions.
This document is The Open Group Microsoft Word template for technical publications. It should be followed to ensure a unified approach to producing document source. This document is intended for anyone who drafts or writes technical documents for publication by The Open Group using Microsoft Word. Editors should also refer to The Open Group Technical Publications Writing Style, Doc. No. I801A. References to menu options and window layout are based on Microsoft Office Word 2007.
For brand identity, which includes font usage, colors, trademark usage, etc., editors should refer to The Open Group Brand Identity Manual which is available on request for use in developing The Open Group documents.
This document is The Open Group Guide to Data in MSA. It has been developed and approved by The Open Group.
All trademark references should be listed here.
The Open Group trademark statement should remain unchanged. You should make every effort to list other trademark and product attributions used in the document. The general disclaimer text should be used to cover missing attributions.
Within the document, please adhere to the trademark usage guidelines for all trademarks of The Open Group. If in doubt, refer to www.opengroup.org/content/legal-trademark-guidelines.
In particular, note that:
* A trademark should be used as an adjective, not as a noun
* A trademark should not be used as a verb
* A trademark should never be used in the plural form
* A trademark should not be hyphenated or abbreviated
* A trademark should not be used in a possessive form
ArchiMate, FACE, FACE logo, Future Airborne Capability Environment, Making Standards Work, Open O logo, Open O and Check certification logo, OSDU, Platform 3.0, The Open Group, TOGAF, UNIX, UNIXWARE, and X logo are registered trademarks and Boundaryless Information Flow, Build with Integrity Buy with Confidence, Commercial Aviation Reference Architecture, Dependability Through Assuredness, Digital Practitioner Body of Knowledge, DPBoK, EMMM, FHIM Profile Builder, FHIM logo, FPB, IT4IT, IT4IT logo, O-AA, O-DEF, O-HERA, O-PAS, O-TTPS, Open Agile Architecture, Open FAIR, Open Footprint, Open Process Automation, Open Subsurface Data Universe, Open Trusted Technology Provider, Sensor Integration Simplified, SOSA, and SOSA logo are trademarks of The Open Group.
Microsoft is a registered trademark of Microsoft Corporation in the United States and/or other countries.
All other brands, company, and product names are used for identification purposes only and may be trademarks that are the sole property of their respective owners.
Any acknowledgements should be listed here. If there are none, remove this section.
(Please note affiliations were current at the time of approval.)
The Open Group gratefully acknowledges the contribution of the following people in the development of this document:
<<To-Update>>
Ovace A. Mamnoon - (MSA Project Co-Chair)
Ovace, a distinguished Chief Architect with over two decades of experience, stands as a luminary in the ever-evolving realm of Enterprise Architecture. Renowned for his pragmatic yet visionary approach to Digital Transformation, he effortlessly harmonizes technology with business imperatives, fostering a landscape of continuous growth and inventive solutions. Holding the esteemed role of Co-Chair at the Open Group's Microservices Architecture (MSA) workgroup, Ovace not only navigates cutting-edge technologies such as Service-Oriented Architecture (SOA), Cloud Native Solutions, the Internet of Things (IoT), and Artificial Intelligence (AI) but actively contributes to shaping industry standards. His strategic insights, delivered with a touch of sophistication, transcend conventional norms, imprinting an enduring mark on the digital enterprise landscape. Ovace's leadership, grounded in practicality yet adorned with a touch of brilliance, remains pivotal in propelling technology-driven evolution.
Peter Maloney, Raytheon Company - (MSA Project Co-Chair)
Peter Maloney is a Senior Engineering Fellow at Raytheon Company. He became interested in Enterprise Architectures and particularly SOA as a result of the ever-expanding need for providing access to increasingly complex data products to a diverse group of end users, with the resulting needs for collaboration, throughput management, and security. He is a Raytheon Certified Architect, a certification accredited by The Open Group, and a three-time winner of the Raytheon Excellence in Technology Award. He holds one patent and has authored more than a dozen papers.
Anurag Choudhry, Tata Consultancy Services Ltd.
Anurag Choudhry is a seasoned IT Architect and Innovation Leader. He has over 22 years of experience in IT and currently he is part of Google Business Unit at Tata Consultancy Services (TCS). He holds TOGAF® 8, Google and Azure Cloud certifications. His key focus areas include Digital Architecture Consulting, Multi Cloud Solutions, Cloud Native Architecture, Microservices Architecture, API and Application Modernization. He has authored numerous papers in reputed international journals.
Chris Harding, Lacibus Ltd.
Chris Harding has been working in the IT and telecommunications industry for over 40 years. Until recently he was Director for Interoperability at The Open Group, where his responsibilities included supporting the SOA Work Group and its MSA Project, and being Forum Director of the Open Platform 3.0™ Forum, whose mission is to help enterprises gain business advantages from recently-emerged technologies including cloud, mobile and social computing, big data, and the Internet of Things. He is now founder and chief executive of Lacibus Ltd., which provides services related to virtual data lakes and data-centered architecture.
John T. Bell, Ajontech LLC
John Bell has worked in the Technology industry for 40 years and in the Hospitality industry for 15. He is an active member of the Hospitality Technology Next Generation (HTNG), The Open Group SOA Work Group, and the IEEE Standards Association. He is the founder and Principle Consultant for Ajontech LLC providing services to hospitality-related companies in the areas of IT Security, Privacy, and Enterprise Architectures. He is the author of several books on software development and was an Associate Professor for the Center of Applied IT at Towson University for 14 years.
Kumar Avishek Singh, Tata Consultancy Services Ltd.
Avishek Singh is an IT Leader with over 22 years of experience in IT. He is an Open Group Certified IT Architect (Open CA). He is working as Chief Architect and Innovation Leader with at Tata Consultancy Services Ltd (Software & Services Business Unit). He also holds TOGAF® 8, Google and Azure Cloud certifications and he has published numerous papers and articles on architecture and technology. His core focus areas include Enterprise Transformation Consulting, Multi Cloud solutions, Cloud Integration, Microservices Architecture and API.
Leszek Jaskierny, DXC Technology - (Lead Author)
Leszek Jaskierny is a Master IT Architect with extensive experience in all stages of software development and delivery. Working for Compaq/HP/HPE/DXC Technology since 2002, he designed complex software solutions and delivered projects for major Financial Services Industry customers. He gained programming, solution development, and project leading experience, building IVR systems, delivering data management projects and front-end applications. His current focus is on Microservices Architecture, IoT, and enterprise-scale distributed transnational systems.
The Open Group gratefully acknowledges the following reviewers who participated in the review of this document:
Referenced documents should be listed here.
To create a reference using the “Ref Docs” style:
1. Insert a tag – such as C220.
2. Add a bookmark to the tag.
3. Insert a <tab> character.
4. Enter the full text of the referenced document.
Ideally, each reference should include the title, author, date, publisher, and document number. Where available, add a URL so that the reader can access the document online.
The preferred style for a document published by The Open Group is:
The TOGAF® Standard, 10th Edition, a standard of The Open Group (C220), published by The Open Group, April 2022; refer to: www.opengroup.org/library/c220
For referenced ISO standards, the tag should include the ISO, ISO/IEC, or ISO/IEC/IEEE standard number only; e.g., ISO/IEC 27031.
Use the tag in-line to link back to the full definition in this section; for example, “… as defined in the TOGAF Standard [C220]”.
This section should be subdivided into Normative References and Informative References using the Unnumbered Heading style. For standards intended to be adopted by ISO, the Normative References should be a forward reference to Chapter 1, for example:
Normative references for POSIX.1-2017 are defined in Section 1.4.
The following documents are referenced in this guide.
(Please note that the links below are good at the time of writing but cannot be guaranteed for the future.)
Tag Full text of reference
<<To-Do>>
https://en.wikipedia.org/wiki/CAP_theorem
https://en.wikipedia.org/wiki/Strong_consistency
OASIS SOA Reference Model – http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf
All commentary (boxed and shaded text) is guidance and should be deleted after use.
Use a copy of this template file to develop your document, making every effort to avoid making changes to the style definitions.
All new sections in the main body of your document should begin on an odd-numbered page, where practical. (This is less important now that electronic publication is the norm.)
Each chapter covers one main topic. If there are sections or subsections, there should ideally be more than one.
Page numbering should be continuous throughout the document.
Data is ubiquitous to all solutions, including Microservices Architecture (MSA). Mishandling data can risk violating key MSA characteristics like independence and self-containment.
This Viewpoint paper explores the challenges and best practices for handling data in MSA without compromising its core principles. Data is crucial for all solutions, including MSA, however, mishandling data can jeopardize the benefits of MSA, like resiliency, scalability, and development agility. This paper explores the complexities of data and MSA interaction, ensuring the preservation of MSA's primary advantages.
The paper builds upon The Open Group Microservices Architecture White Paper, which defines MSA as an architecture style that creates systems using small, independent, and self-contained services aligned with business activities. These services manage data individually and are stateless, not storing activity state between operations.
The central question explored in this paper revolves around which data should be contained within Microservices and what should be kept outside, while maintaining their self-containment and independence characteristics. This question is not easy to answer, and the industry is evolving with new data architecture styles like Data Mesh.
The data persistence capabilities required within an MSA must align with its characteristics, such as resilience and elasticity. Resilience ensures that stored data is as reliable as the services. Elasticity allows the number of active service instances to adjust based on demand, necessitating distributed data storage to maintain availability to all active instances of Microservices.
In conclusion, handling data in MSA requires addressing unique challenges while preserving the core principles of microservices. Resilient and distributed data storage solutions are necessary to ensure consistency and enable the benefits of MSA, allowing organizations to achieve high levels of efficiency and effectiveness in their architecture implementations.
This section should contain a brief statement of the objective of the document. For example:
The objective of this document is to specify a standard template that can be used to develop The Open Group publications.
This guide will take you on an exploratory journey from a foundational understanding of this complex problem space and through various scenarios and several Architectural patterns that successfully address it.
Use this section to describe the scope, context, etc. This section should not contain an overview of the contents of the document – you should use the “This Document” section of the Preface for that purpose.
This White Paper builds on The Open Group Microservices Architecture White Paper to explore the treatment of data in microservice architectures.
The Open Group Microservices Architecture White Paper defines Microservices Architecture (MSA) as: “A style of architecture that defines and creates systems through the use of small independent and self-contained services that align closely with business activities.” In MSA, data management is performed by individual, self-contained, services. These services are not orchestrated or choreographed in the performance of their business activity, and encompass all IT resources necessary to support the work. The definition of microservices in that white paper also says that they are stateless, so that they do not store activity state between operations.
An MSA is a subset of a Service Oriented Architecture (SOA). There is always an explicit or implied contract between the service provider and its consumers. A microservice instance performs its function according to its contract. The contract includes the specification of the data produced or ingested by the service. It also includes the protocols and message formats for the data exchange.
MSA is a style of architecture that defines and creates systems using small independent and self-contained services that align closely with business activities.
Microservices are the primary architectural building blocks of an MSA. An MSA has the following three key characteristics:
For more detail on characteristics, features, and Governing Principles of Microservices and MSA, please refer to The Open Group “Microservices Architecture” (W169) whitepaper.
Following are the key benefits of using Microservices:
The definition of microservices in that white paper also says that they are stateless, so that they do not store activity state between requests. When a service is stateless, the client or consumer maintains the activity state, not the service. Each service call by a consumer is independent of other calls made by any consumer.
Activity state is different from resource state. Resources represent the underlying data. The state of a resource reflects the values of the elements that form the resource. For example, a name resource might have the elements: id, title, first-name, last-name, and suffix. An individual instance might read, “421”, “Mr.”, “John”, “Doe”, “Esq”. An update operation might look like, “update id=”421”, last-name=”Dove” to change the last name from Doe to Dove.
The proposition that a service shall encompass all data sources necessary to support the business activity merits some discussion. Suppose that a System includes a set of customer records containing information that is needed by Sales, Dispatch, and other business processes. It might have a customer microservice that offers operations to retrieve, add, and update customer records. The system may include a Shipping application that uses the Customer microservice and other microservices supporting Sales, Dispatch, and other business processes. The application retrieves data from the Customer microservice and passes it to the microservices (Sales, Dispatch, etc.) that need it. At any given time, each of these microservices may have several running instances. Each instance includes physical data representing information in customer records. These physical data sets are separate. They are not shared between microservices, or between instances of the same microservice. It is the information that they represent that is shared.
The data persisted by the microservices should be consistent. Because individual microservice instances can fail, persistence dictates that, at any time, there are multiple instances with physical copies of the data representing each piece of information. Consistency dictates that, at any time, the copies of the data representing a piece of information should as far as possible be equivalent (as required by the needs of the system). The questions of persistence and consistency are complex, and are discussed later in this Guide.
This paper takes a more purist approach to MSA solutions, strictly adhering to the core characteristics of Microservices being stateless, atomic, and ephemeral. As this topic developed within the Open Group MSA Workgroup, it became evident that the MSA solutions, in the industry, fall in the spectrum from more purist, as addressed by this paper, to more pragmatic Where the purist adheres to all of the Microservice characteristics and the pragmatist waives those that may not be as relevant to the specific project with the potential loss of some of the MSA benefits.
Further discussions about the benefits of MSA purity, versus limited application of MSA principles are left for future papers.
In order to maintain true independence between microservices, we cannot allow two different microservice instances to rely on the same physical piece of data, regardless of how that data is stored. Loss or corruption of this single piece of data would deprive both microservice instantiations of information needed to complete their required function. However, it is quite common for microservices to have multiple physical copies of the same data. This sharing may lead to contention if multiple microservices are trying to update the same record; Case Study 1 illustrates one way of mitigating this contention.
A service instance gets data in only three ways:
For example, suppose that an online shopping microservice uses a list of customers to look up shipping addresses. Each instance could be given a copy of the list when it is created. When there is a new customer, the application that is the consumer of the microservice could use an “add customer” interface defined in the service contract to add a customer to the list. The instance handling the add customer request would add the customer to its copy of the list, and invoke the other instances so that they would update their copies. Alternatively, the list could be held in reliable external storage (which must be both resilient and scalable) used by all the instances, with the interface to that storage defined in the service contract.
Because microservices are stateless, each operation can be performed independently by a different microservice instance. It also means that it is the responsibility of other system components external to the microservices, and not of the microservices themselves, to ensure that the data is reliably persistent when individual microservice instances fail.
Eliminating physical sharing of data and making microservices stateless enables run-time independence of microservices and their instances, and simplifies the design of the microservices themselves, but it means that the design of other system components, external to the microservices (for example, in the application layer), must address the key problems of:
This White Paper explores how data should be treated in microservice architectures. It
. It builds on the foundational work published in the Open Group “Microservices Architecture” (W169) whitepaper. It was developed by the MSA workgroup team in collaboration with other Open Group forums.
This guide explores architectural constructs for solutions that expand beyond the MSA boundary for interaction with, and persistence of, data. In all these, it requires that all Architecture Building Blocks (ABB) of the solution have the level of Resiliency, Availability, and Scalability consistent with that of the MSA.
The characteristics of independence, self-containment, and decoupling, imply that the MSA must take on the responsibility for all its managed data resources. It cannot for example be dependent upon a legacy, single, or external database for normal operations. It also implies that the data managed by the MSA should be the primary or “Authoritative System of Record” or authoritative source of data for the other systems within the enterprise.
This does not mean that data cannot come from external sources, rather it implies that any data from external sources can’t create dependencies for the operating services. If the external source of data is unavailable the services provided by the MSA must remain fully operational. Furthermore, the ability to extract data from the MSA and send it to other systems for analytics and other uses must operate without impact to the performance or resilience of the operating microservices.
This leads to a Data Principle: an MSA must be the authoritative source of the data managed by its services. The rationale is that if the MSA is not the authoritative source it is in violation of the independence principle.
Part No.: Part Title
If your document contains major sections covering separate topics, it may be sensible to divide it into parts.
Copy this section to create further parts.
The Part page is derived from the Title page.
Edit the part number (which uses the Part Number style) and part title (which uses the Part Title style) as appropriate.
Part pages would normally appear on an odd-numbered page.
When we discuss storing data in a system, we are typically discussing persistence. In computer engineering persistence means that the stored data remains the same after a system is stopped and restarted. This data may be unstructured or may have a structure overlaid upon the data. The primary purpose of structuring data is to make specific pieces of data easier to access. Filenames for example, allow access to a specific data file within a file system. A file on randomly accessible media, like a storage disk, is accessible sequentially from the first byte or octet to the last one in order, or randomly allowing a process to jump to a specific location within a file.
Storage systems such as Cloud Object Stores, allow data to be stored as objects and retrieved using unique identifiers. These systems may also have file systems overlaid on top of the storage system allowing access using the common file system paradigms.
In a highly available distributed system like one based on an MSA, storing data once is not adequate to maintain high availability goals. Just as service instances are duplicated the data they store also requires duplication; typically this is handled by the modern Distributed Data Storage Systems and not separately addressed. The number of replicates required is elastic and varies according to the requirements of the system.
Modification of data in one service instance requires the modification of the data managed by other instances as well. When retrieving data, we want to assure the data returned is a consistent record as discussed in the “Consistency” section.
A key principle for an MSA is that of self-containment. This means that a microservice must encompass all of the resources and most importantly data sources required to perform the desired atomic business function. Why is self-containment important? For development and deployment purposes, self-containment ensures that microservices are inherently easily upgradeable and replaceable, since they can be added or updated without interfering with the operation of other microservices. However, self-containment takes on a whole added dimension when we begin considering the question of data storage. Figure 1 below illustrates the problem. Here we have three different clients, A, B, and C, which have called three different microservices, which are modifying data items in a distributed database. (The distributed database in this case is treated as a black box; patterns for persisting the data in an MSA are discussed below in “Data persistence in MSA solutions”). A fourth client, D, then issues a data query to that database. How can we guarantee that our microservices are retrieving the most recent value of a particular data item? How can we be sure that multiple instances of a particular microservice which might be querying, for example inventory, do not write on top of each other as they compete to perform updates on the same datum? Although these are not new problems in data storage, they are greatly complicated by distributed and cloud architectures, where data may be stored in geographically disparate locations for any number of reasons, both technical and business.
Whatever our data storage solution is, it must also not compromise the needs for independence and reliability of the microservices, which are some of the key benefits of implementing an MSA, providing scalability and resiliency to the system. Introducing dependencies via data storage is just as undesirable as creating dependencies between microservices. The solution to these problems is the subject of this paper.
Client
A
Microservice A
Microservice B
Microservice C
Client
B
Client
C
Data node 1
Data node 2
Data node 3
Distributed Database
Client
D
Microservice D
Figure 1 - Competing Microservices In A Distributed Data Environment
An MSA that needs to persist data must do so without violating the MSA principles. Three scenarios reflect the various ways data can be persisted if needed in an MSA without compromising the MSA principles or characteristics.
The MSA stores no data and only operates on data fed into it by a consumer of the services or static data pre-loaded into the MSA without changing while the system is operating.
In this first scenario, the MSA stores no data and manages no resources. It only operates on data presented to it by the client or pre-loaded into the system. This pre-loaded data typically does not change while the service is in normal operation. The service does not have any support for write or store operations.
The microservices make use of established tools or components to store data, in a manner consistent with the scalability, availability, and other characteristics of an MSA. This might be a data grid or another reliable, distributed, redundant data storage structure leveraged by the MSA.
The Microservices are responsible for the provision of data persistence capabilities that are consistent with the MSA characteristics. In other words, when data is stored the microservice instances have the responsibility to replicate and balance the data across multiple service instances to guarantee the robustness of the system.
The focus of the three (3) patterns below is on the synchronization between the ephemeral data store that is dedicated to a Microservice, to successfully meet the Independence and self-containment characteristics of MSA, and the persistent external data storage.
Case 1 - DEDICATED FOR EACH MICROSERVICE INSTANCE
This is the most common pattern where each Microservice instance has a dedicated data storage represented as data object in diagram. This is typically a volatile storage such as a cache or in-memory data store that has a life span same as the Microservice Instance. Each Microservice can have multiple ephemeral instances to cater to the workload demand. This diagram illustrates two (2) Microservices – A & B – each with multiple instances.
Data that needs to be available across the Microservices and past the life of the Microservice instance is persisted in an external data store that is typically distributed, highly available, and highly scalable to successfully meet the availability and resiliency requirements of an MSA.
The synchronization of data between the Microservices and the external data store, in this case, is handled by the Application component in the Interaction layer and via the standard interface of each Microservice.
Eg. << We discussed multiple examples when we were discussing these scenarios in detail. I did not take notes of those. 😊. If someone else has a good recollection of them and describe them here, that will be helpful to the reader. If not I’ll make one up for each, but would prefer one already discussed over a new one>>
Case 2 - External synchronization via queues/message bus and Application instance
In this pattern the synchronization with external, persistent, data store specifically caters to asynchronous use cases. The introduction of a Queue (or a message bus, or event bus) enables async pub/sub patterns.
At a change of state of Microservice A, it publishes the to the Queue. The application component (and others, there can be multiple subscribers and multiple publishers) subscribes to a particular Topic (or Subject) of interest on the Queue. When such is published the Application component retrieves the relevant information from the Queue and synchronized this with Microservice B.
Similarly, the External, Persistent, data store subscribes to particular Topics (or Subjects) on the Queue and when new, relevant, information is published by the Microservice the Data store retrieves and synchronizes this information.
A variation of this pattern is where the Application component handles the synchronization with Microservice B and the External data store as in Case1. This introduces additional complexity in the Application component.
Case 3 - External synchronization via queues/Message Bus
This pattern is a simplification of the pattern in Case 3, eliminating the Application component in the interaction layer, to handle synchronization between Microservices and with the External, persistent, data storage. This is a pure async Pub/Sub implementation. Each Microservice interface is capable of Publishing and Subscribing to Topics (or Subjects) of interest on the Queue.
This also allows for true decoupling, where the Publishers have no knowledge of the Subscribers and vice versa. The common thread is the Topic (or Subject).
Microservice A Publishes a change of state to the queue via its Interface. Microservice B (and the external data store) are listening (Subscribing) to the Topics of interest on the queue. When they detect any such, they retrieve the relevant information from the queue and synchronize.
For clarity of explanation, the diagram shows the flow of information from Microservice A to Microservice B. This can be in the other direction as well. Each Microservice can be a Publisher as well as a Subscriber, albeit to different Topics.
If your document contains major sections covering separate topics, it may be sensible to divide it into parts.
Copy this section to create further parts.
The Part page is derived from the Title page.
Edit the part number (which uses the Part Number style) and part title (which uses the Part Title style) as appropriate.
Part pages would normally appear on
The problem of data consistency was introduced in the section on “Self Containment Revisited”, with the example of three different microservices (A, B and C) modifying data which is then read by a fourth (D), raising the question of how to be sure that multiple microservice instances do not write on top of each other as they compete to perform updates on the same datum. We want D always to retrieve the "right" data, but saying what we mean by "right" is not easy. Ideally, we want the latest values but, when there are several copies of the data, and A, B and C are changing them at the same time, we may not know which these are. What we don't want is for D to retrieve data, part of which has been written by A, and another part of which has been written independently by B or C, where the parts don't match. We want the data retrieved by D to be consistent.
Merriam-webster defines "consistency" as "agreement or harmony of parts or features to one another or a whole". In data processing, this means that the data satisfies some set of rules. For example, in a retail application, the quantity of stock at any time should be the quantity in stock at the start of the day plus the quantity of new stock delivered minus the quantity sold. In a set of balanced accounts, the total value of the assets should equal the total value of the liabilities.
Ideally, the consistency rules for data retrieved by a service should be defined in the service contract. In practice, there are often additional implicit rules. The contract of a stock control service might explicitly say that retrieved stock levels must take account of all stock sold, but the contract of a banking service might not explicitly say that the totals of the assets and liabilities must be the same, because this is what everyone understands by "balanced accounts".
Not all rules stated in or implied by a service contract are consistency rules. For example, the quantity of stock recorded for a delivery should be the actual quantity of stock delivered. This is a validity rule, but not a consistency rule. Consistency rules relate to agreement between data values, not to other aspects of system operation such as data accuracy, security, or performance.
We define "consistent data" as "data that satisfies the consistency rules stated or implied by the contract of the service that delivers or writes it."
Within this overall definition, there are different types of consistency that are important for use of data by microservices[1].
The design of an MSA ensures that consumers of a microservice only see completed results. They cannot read data byte-by-byte. This is implied by the principle that microservices do not share memory, and achieved by use of mechanisms such as HTTP, message busses, and queues. The microservice writes a record, and the mechanism gives it to the consumer, but only after the microservice has finished writing it. Similarly, the microservices only see completed inputs from users.
This means that the consistency rules apply to completed records, not to data being processed or in transit. This is illustrated in Figure x, which shows two clients accessing a stock control system. At the start of the day, reads by both clients return the overnight stock level of 5 items. Then there is a sale of one item, recorded by Client A. When Client B reads the stock level while the write by Client A is still in progress, the returned value does not reflect the result of that write.
Figure x: Read While Write is in Progress
This gives clarity to terms such as “latest” or “current” data. They refer to records described in a service contract that have been completed before the point in time when the system is viewed.
The first distinction to make is between consistency of related data items at a single point in time and consistency of data, including consistency of a single data item, over time. For a system to be consistent over time, its data as seen at any point in time should reflect the results of operations completed before that point.
For example, a client of an accounting system might make a funds transfer. A subsequent request for the balance sheet might return the figures as they were before the transfer. The system is consistent as regards consistency of related data at each point in time, because the assets and liabilities still match. Consistency over time requires, not only that the values for assets and liabilities are equal, but also that they reflect all previous transactions. For the system to be consistent in this sense, the request for the balance sheet must return the figures obtained after the transfer.
The second key distinction, particularly important for distributed systems, is between consistency of the data as seen by a single client, and as seen by multiple (usually all) clients. For example, if the transfer is made in New York, a client in Shanghai might see the previous balance sheet while a client in New York sees the current one, because of propagation delays in the system. For consistency of data seen by multiple clients, requests made at the same time in New York and Shanghai must return the same result.
Strong consistency means that the data as seen by all clients is consistent over time. The data seen by any client at any point in time must reflect the results of all operations completed before that point, whether they were made by that client or any other. It must be noted that this consistency is from the client view, and may not be fully reflected in the internal state of a distributed system.
Strong consistency of related data as seen by multiple clients is illustrated in Figure x. Client B reads the stock level when the write by Client A is complete, and the returned value does reflect the result of the write.
Figure x: Strong Consistency
Eventual consistency means that the results of an operation made by a client are reflected in the data read by all clients at some (possibly notional) future point in time, when the system has stopped receiving inputs. For example, it may be acceptable for a query on stock levels not to take account of the latest sales. It would however be expected that, at the end of the day, when trading has finished, the stock levels returned take account of all the day's sales.
This is illustrated in Figure x. Client B reads the stock level immediately after the write by Client A is complete, and the returned value does not reflect the result of the write. A later read after a time when there have been no new inputs or deliveries, and the data has propagated through the system, returns the correct value.
Figure x: Eventual Consistency
The term weak consistency is sometimes used, but there is no real consensus on its meaning, other than it is not strong.
In transaction processing, consistency means that a transaction preserves consistency of related data items in a database. In a distributed microservices architecture, where different instances of a microservice can hold different values of the same data elements, it is not obvious what “consistency of the data in the system” might mean. There are a number of possible ways of defining authoritative values whose consistency could be measured, but analysing them is beyond the scope of this Guide. Assuming that “the data” means “the data as seen by all clients,” transactional consistency is practically the same as strong consistency of related data.
A microservice contract may contain provisions that require different types of consistency. For example the total stock deliveries might have to be strongly consistent and include all deliveries that have been input to the system, while total stock levels might not have to include the latest sales, and only be eventually consistent with the sales data.
The consistency rules of a microservice contract can apply, not just to a single record, but to multiple records that may be written by multiple instances of the microservice. There can also be consistency rules at the system level, that apply to records written by different microservices, and are part of the contract of each of those microservices. For example, sales and stock control might be different microservices, and a system-level consistency rule might say that the stock level returned by the stock control service at the end of the day must equal the stock level returned at the start of the day, plus deliveries, minus the sales returned by the sales service.
They can also apply, not just to interactions with a single client, but to interactions with multiple clients. For example, they might say that the stock level retrieved by a client after that client has made an update must always include the value of the update (read-after-write consistency). Alternatively, they might say that the stock level retrieved by any client must always include the value of the update (strong consistency).
The famous CAP theorem, which states that a distributed data system can have at most two of the three properties: Consistency, Availability, and Partition Tolerance, assumes that consistency means strong consistency.
In general, an MSA should be available and partition-tolerant. In the light of the CAP theorem, this means that strong consistency cannot be guaranteed. Eventual consistency is the default assumption, and is usually good enough. There are however ways in which strong consistency can be achieved if necessary, by sacrificing availability or partition-tolerance. These require external mechanisms outside the Microservice Architecture Boundary and are not in scope of this paper.
When creating an MSA, an architecture team identifies a number of consistency requirements, taking into account the concerns of the business stakeholders and the possibilities for implementation. The business stakeholders agree that various types of consistency (strong, read-after-write, eventual, etc.) should apply in various use cases. The architects may need to explain implementation difficulties and costs to obtain agreement on, for example, eventual rather than strong consistency.
The architects can then design a system that meets the agreed requirements. They should consider whether an MSA is appropriate. If it is, then they will select any existing microservices that can be used, and specify any new or updated ones that are needed. This will include defining their service contracts, including validity rules for consistency. They will also specify the application that uses the microservices, and their environment.
The application can have absolutely no effect on the level of consistency provided by a microservice, and as part of the overall system design, it is the responsibility of the architects to select the appropriate microservices, whether existing or new, which provide consistency compatible with the overall system requirements.
Each microservice should be defined to perform an atomic business function. However, there is no absolute definition of what a business function is (ref: first Paper on MSA). Identifying and describing the business functions to be performed by microservices is a difficult task, requiring considerable skill and judgement. The architects must consider a number of factors, and consistency is an important one.
The consistency rules that apply to the data are business rules. Often, a consistency rule will be associated with a particular business function. The microservice performing that function should be responsible for consistency in accordance with that rule, and this should be part of its service contract.
If a rule applies to data associated with more than one business function, then the microservices cannot collaborate to enforce it, as this would mean a dependency between them. Responsibility for it should be given to the application. For example, rather than trying to co-ordinate the sales and stock control microservices to deliver stock levels that take account of sales, it is better to have the application query them separately and subtract the amount sold from the amount in stock. The result may be approximate while trading is in progress, but this is acceptable given that the requirement is for eventual consistency.
Section on “Data Storage Scenarios” identifies the three fundamental MSA storage scenarios:
The MSA does not Persist Data
The MSA Leverages Established Tools to Handle Persistence
The Microservices Provide Data Persistence Consistent with MSA Needs.
The data output by a microservice as seen by any single client at any point in time should always be consistent. The three storage scenarios have different implications for consistency over time and consistency as seen by multiple clients.
In this scenario, the microservices cannot provide consistency over time or for data as seen by multiple clients.
In this scenario, a microservice can provide consistency over time or for data as seen by multiple clients, and can use the established tools to help it do so.
A data store may be able to help ensure consistency of its data. An "ACID" transactional database can guarantee the consistency of data that is read and written by SQL queries. A cloud object store can guarantee atomic reads and writes of each stored object.
Where the data store cannot completely ensure consistency, the microservice instances can use mechanisms such as queues, locks and semaphores to co-ordinate data access. For example, a stock control microservice instance might use a lock to prevent other instances accessing the stock records while an instance is updating them for a delivery. Care is needed when using these mechanisms to ensure that failure of an instance does not cause the service to fail or hang. For example, there must be a way of removing a lock set by a failed stock control instance so that other instances can reverse any incomplete changes and make further updates.
The mechanisms needed to guarantee consistency in real-time, distributed systems can be hard to program, and very hard to test. Where external components, such as “ACID” databases can provide them, it is strongly recommended to use these components rather than to try to replicate their functionality in microservice code. They must however meet the system’s reliability and persistence requirements: there is no point in designing an MSA with replicated service instances and then introducing a singleton database as a single point of failure.
In this scenario, a microservice can provide consistency over time or for data as seen by multiple clients, but cannot use external data stores to help it do so.
As in scenario 2, instances of a microservice can use various mechanisms to help ensure consistency of the microservice’s data.
Where microservice instances have the responsibility to replicate and balance the data across multiple service instances to guarantee the robustness of the system, the design must meet the requirements for consistency as well as for persistence. For example, if the full replication pattern is used, it may be necessary to check the state of replication of the different data elements covered by a validity rule. Mechanisms such as locks and semaphores can be employed to ensure that the same replication operations have been carried out on all the data.
Part No.: Part Title
If your document contains major sections covering separate topics, it may be sensible to divide it into parts.
Copy this section to create further parts.
The Part page is derived from the Title page.
Edit the part number (which uses the Part Number style) and part title (which uses the Part Title style) as appropriate.
Part pages would normally appear on
The data persistence capabilities required within an MSA must be consistent with the characteristics of an MSA. The stored data must be resilient and reliable just as the services behind the data. Let’s now examine the implications for data stored as a part of an MSA.
The characteristics of resilience and elasticity imply a distributed pattern for data storage. The Elasticity characteristic provides the resilience of an MSA. It allows the number of individual active instances of a service within the MSA to increase and decrease with demand. As demand increases or Service Instance fail, new Service Instances are added to address the need. As demand decreases the number of Service Instances is decreased. The data managed by the MSA must still be available for each active Service Instance, regardless of the reason for a new microservice instance.
Expanding or contracting the service instances may require adjustment in how the data aligns with the instance structure so that the entire collection of data remains available to all active Service Instances.
This is independent of the cause, whether the change in the number of instances is caused by failure of an existing instance or because of changed demand. This leads us to the conclusion that the data must be distributed redundantly to provide the required resilience.
The CRUD operations are Create, Retrieve, Update, and Delete. These provide the core operations for date storage.
The Create operation creates or inserts new data into the storage medium. In distributed systems it is important that this new data element be placed correctly into the correct data or service instance so it can be found from any other service instance.
The Retrieve operation recovers data that has been stored so the data returning it to a requesting client. The data may be in a constant state of change so it may be necessary to consider if the application must receive the most recent value stored or if any recent value is acceptable as a response to the operation even if it is not the latest.
The Update operation provides the ability to change or modify the data that has been stored. In a distributed data system with data redundancy each copy of the data must be updated.
The Delete operation removes data from the system. In a system where each data element may be represented by multiple copies, it is important that all copies are deleted.
It should be apparent that these primitive data operations become more complex in an environment where the data must be redundant to ensure the robustness of the data in an MSA environment.
In an elastic environment like an MSA the number of instances increase and decrease according to the demand requirements. As the demand for the services increase, the number of instances increases and as the demand decreases the number instances decreases. If each service instance is responsible for a share of data, then the data must be redistributed as the number of instances increases and decreases. This is the model discussed in storage scenario 3.
If the distributed data instances are managed separately from the service instances, the redistribution can be handled by the data storage component and the rescaling can occur separately as covered in storage scenario 2.
An MSA is supposed to be self-contained but sometimes data needs to originate externally. Consider for example a weather report, updated daily, and used until updated again. This extracted data is stored within the MSA services to mitigate any dependencies on the system of source for the data. The “Bulk Load” capability needs to be able to “batch” load the data from an external source without having an impact on the service operations.
It might also be required to extract data managed by the MSA for use in other systems that cannot leverage the service interface or might have an impact on the service operations. The data provided would be a snapshot of the state of the MSA data at a particular point in time. Consider extracting a daily summary of sales for use in an analytics system. This bulk extraction operation needs to be able to occur without impact on the normal operations of the underlying services.
To summarize, for an MSA to manage data storage without violating the MSA principles or characteristics the capabilities typically required are:
The architect of the MSA based solution may decide to waive the availability requirements of incoming bulk operations. These operations are suitable for data not maintained by the MSA but used for internal purposes or republished by the services of the MSA. Extracts provide a mechanism to share data for offline analytic processing without creating dependencies on external systems to immediately receive the data.
Part No.: Part Title
If your document contains major sections covering separate topics, it may be sensible to divide it into parts.
Copy this section to create further parts.
The Part page is derived from the Title page.
Edit the part number (which uses the Part Number style) and part title (which uses the Part Title style) as appropriate.
Part pages would normally appear on
MSA implementations have a common concern when it comes to data storage. The practice of storing the data cannot allow compromise the principles of the MSA. A single point of failure negatively impacts the resilience and availability of a microservice. A microservice must also be self-contained, implying that all data needed by that microservice must be contained by the micro-service itself. The patterns covered in the following sections address potential solutions to this dilemma.
Full Replication
Data is completely replicated across all Service Instances
Overlapping Sharded Data Store Pattern
A data set that is horizontally distributed across multiple Service Instances typically achieving redundancy by each Service Instance containing row data that overlaps rows on one or more other Service Instances.
Bulk Data Export
Data is required for offline processing for analytics and other uses that are needed but should not impact production operations.
Bulk Data Import
A data set that is managed externally but required by the MSA is imported to the MSA environment and the operating MSA environment is reconfigured to use the newly imported data instead of the old data.
Data is completely replicated across all Service Instances. The complete set of persisted data is replicated for each Service Instance of a Microservice as the Service Instance is created and if data is added, deleted, or modified during operation the action is replicated for all active Service Instances until all Service Instances are consistent with the first Service Instance that processed the change.
Common information like translation tables and code lists need to be available to each Service Instance when the Service Instance becomes operational. Additions, updates, and deletions need to occur on all Service Instances and on the primary image used to create new Service Instances.
There are several ways to implement this pattern, for example using distributed queues or broadcast messages to communicate changes to each Service Instance. In many cases the data to be stored is relatively static and changes slowly. This data can be maintained by updating the Service Instance image with the revised data and then forcing subsets of Service Instances to restart with the new image until all Service Instances have been restarted with the new data.
An MSA service calculates the shipping costs for merchandise orders. The service needs to store shipping rates by weight between various regions as identified by postal codes. These rates are typically published with changes each month.
Scenario: Small Fleet of Vehicles
An MSA service is used to track the locations of vehicles within a small fleet of vehicles. The list of vehicles and their identifications is used to look up the means to access the current location of the individual vehicles. Vehicles may be periodically added to or removed from the list as they are added to and removed from the fleet. These changes to the fleet list are automatically replicated across all Service Instances.
Small tables that are static for a period of time can be included in the image build and refreshed as the build is deployed avoiding any additional infrastructure for synchronization.
Many applications have need to use small lookup tables. Replication is a good solution for these small tables especially if they do not change quickly. Other patterns are more suitable for larger tables or those with high rates of change.
The Overlapping Shards Pattern distributes data across multiple Service Instances by using shards to divide the data horizontally across Service Instances and replicating data so that it is duplicated in two or more Service Instances. No individual Service Instance contains all of the data, but each datum exists in multiple Service Instances. This provides the redundancy required for high availability without the storage costs of complete replication. It may also provide potential performance benefits by supporting distributed search capabilities.
In an MSA, data needs use replication to achieve the reliability and availability goals but full replication of large data stores is costly in the amount storage required.
Standard distributed database techniques of horizontal distribution can be applied to an MSA to provide the reliability and availability desired in an MSA. A horizontally divided data store allows a data store to be divided across multiple Service Instances. Overlapping the data shards in a way that guarantees the data is replicated multiple times provides the redundancy needed to achieve the high availability goals of the MSA. Shards are redistributed as needed to support adding and removing Service Instances in an elastic environment.
Scenario: Hotel Inventory Database
A large hotel company with thousands of properties globally wants to use an MSA to manage property room inventory. The global room inventory database is distributed using a sharding function that allocates inventory datums to a single property Service Instance and at least two additional Service Instances that may be associated with other properties. This distribution not only provides the resiliency needed but also allows faster parallel inventory searches.
Most table oriented storage systems can be easily converted to use horizontal shards.
The shard scheme can also provide additional benefits such as parallel searching if selected carefully.
Overlapping shards addresses the resilience, availability, and reliability needs of an MSA and can benefit from existing technology solutions.
A snapshot of the data in the system is extracted and exported to different systems for use in Online Analytical Processing and other processes that do not have the availability and other performance requirements of an MSA.
Frequently analytical processing and reporting negatively impact operations in a transaction processing environment as is typical for an MSA.
Replication of a snapshot of the data at a point of time is a common solution for this concern. Processing the snapshot does not impact the performance, reliability, or availability of the services that are a part of the MSA. The extract process must be designed so it does not impact performance of the MSA and may be based on extracting only the changes in the data since the last extract.
A used cars sales company adjusts their vehicle pricing weekly based on available cars, pricing of competitors for similar vehicles, expected weather, and other considerations. The pricing is generated using an analytical process that also considers factors like industry pricing databases, auction prices, weather, and calendar events sales for example. Once the analytics have been completed new pricing tables are uploaded to the price quoting system.
A number of strategies can be used to generate the extracts. Some to consider are:
Offline processing is an important component of many real-world business processes. This patterns provides a mechanism for offline processing without impacting the operations of the MSA.
Not all data that is used by an MSA is maintained by the MSA. Data like lookup tables, pricing tables, tax tables, and shipping tables are frequently generated by external sources and provided as static resources for use by the MSA. These static resources may change but the changes tend to be slow and often are implemented by replacing the entire data set at one time.
Data that is not needed on a real-time basis is often required to generate the results returned by a microservice. Examples of this type of data includes; shipping tables and tax tables. This data needs to be imported into the system to replace the existing data without impacting the performance of the services they support.
The data can be replaced in a service instance that is currently offline. When the service instance is enabled the new data will be reflected in the results.
A used car company acquires much of its inventory through purchases from regional auctions. The shipping costs of the vehicles vary monthly based on a number of factors including source and destination regions, average fuel prices, and other factors. The shipping price tables are provided to the dealers monthly and impact the sales pricing of new cars arriving at the sales lots. These tables are added to the microservice environment for the services to calculate an accurate price.
There are several strategies that can be used to update the tables while minimizing the impact on the performance of the MSA.
Offline processing is an important component of many real-world business processes. This pattern provides a mechanism for offline processing without impacting the operations of the MSA.
Part No.: Part Title
If your document contains major sections covering separate topics, it may be sensible to divide it into parts.
Copy this section to create further parts.
The Part page is derived from the Title page.
Edit the part number (which uses the Part Number style) and part title (which uses the Part Title style) as appropriate.
Part pages would normally appear on
So far, this paper has identified the complexities of the problem when dealing with Data persistence and consistency in a MSA, and presented some viable capabilities and patterns that successfully address these problems in various scenarios. We admit that these are difficult to comprehend in the abstract. The case studies that follow are derived from real MSA solution implementations and demonstrate the use of some of the patterns described above.
The following case study provides an example of the implementation of MSA in the Public Cloud, where microservices leverage Cloud Infrastructure for persistence of the data, using “Distributed Systems and Files”, described in the “Patterns” section.
This case study also highlights the clear separation between data managed by individual microservices, both from the business perspective and technical perspective.
A major bank has decided to migrate its application infrastructure to the Public Cloud. The main reasons for the migration were:
The system selected for the migration was a backend for the mobile application. From a technical perspective, the system performs the following operations:
The functions provided by the monolithic application were decomposed into a microservices solution which replaced the application. Microservices were developed as stateless components, with direct dependencies only on the services provided by the cloud infrastructure, including:
Functional services have been called “Business services”, which are focused exclusively on the business functionality.
From the data perspective, each microservice is responsible for an exclusive set of data, not shared with the other microservices. This is achieved using shared databases provided by the cloud infrastructure, but which are divided into individual schemas for each microservice.
The Cloud database is a distributed core infrastructure component for this MSA. It addresses the needs for resiliency, availability, and persistence of the data, avoiding dependence on any single instance.
Stateless “access services” are another type of microservice developed for the new system. These services implement both standard and proprietary security mechanisms required by the mobile application. Additionally, these access services manage the distributed session object, stored in the cloud-based cache, and this is where client session state is managed. The session object has been designed primarily for optimization of the communication between the mobile application and the backend; it stores information required by the business services that don’t need to be sent within each request from the mobile application.
The new Microservices Architecture, broken into several layers, introduces a clean design, where business services are stateless, highly re-usable, and prepared to support future implementations (e.g., supporting new distribution channels, or communicating with yet unknown backend systems).
This is an insurance domain case study where the business is providing insurance services to their global customers using a mainframe-based legacy application. As part of a large digital transformation program, the business wants to modernize this insurance application while leveraging state of the art architecture styles and patterns.
This case study demonstrates the “Full Data Replication” pattern where the data is completely replicated across all Service Instances
This case study implements the business scenario by leveraging external components to be consistent with MSA Needs. It invokes lightweight integration channels to publish the details of data changes to the message queue. This ensures that each microservice shares its data state in near real-time with the extended application ecosystem.
This case study also illustrates the MSA-Provided Data Persistence scenario. Microservices send a copy of their data to a centralized external data store to ensure data consistency across the ecosystem, and also mitigate the risk of any data loss if a microservice instance fails.
The framework features, like the queue and messaging-based design used in this case study, provide access to framework for the microservices, required to support the characteristics of resiliency via scalability and availability, and persistent storage.
Following are the key requirements:
This solution was built on Microservices architecture leveraging multiple state-of-the-art technologies, resulting in a highly scalable & technology-independent solution. Business capabilities are exposed as a set of independent, autonomous, and decoupled microservices with a private data store for each microservice.
Microservices exchange data with other microservices in a near real time manner leveraging the external lightweight integration channel. When a microservice changes or updates anything, it publishes its change in data to the message queue along with information on “what data has changed”.
Microservices also send a copy of their data to a external centralized data store, to mitigate the risk of any data loss if a microservice fails. That is, even though each microservice has its own database, a change in that microservice data also updates the centralized data store. For example, the Quote microservice persists the QuoteGenerated event of the Quote entity. When events result in a change to the microservice data, this data is published to the messaging channel so that a subscriber (e.g. the external centralized data store) can consume the same. This keeps the centralized data store in sync with all the microservices.
The external centralized data store is also used to share the data across and outside the organization, which helps the microservices to be completely decoupled with applications which do not need data in near real-time. The centralized data store is also used to pre-populate the new instances of microservices to expedite the spinning up of new instances and to meet the scalability requirements. This helps microservices to effectively manage data concurrency in the ecosystem.
An API Gateway was used to take care of cross-cutting concerns ensuring loosely coupled microservices endpoint integration within and beyond the solution boundaries. This helped in keeping each microservice light and focused on enabling a business capability. The decision to leverage external capabilities helped by allowing the microservices to delegate the operational features (e.g. authentication, authorization, logging, data-auditing, etc.), which also helped microservices to be consumer neutral. For example, the enterprise can have multiple authentication and authorization mechanisms to offer to different consumers of microservices. The enterprise can even implement different policies for usage of microservices, such as metering, billing etc.
A large hotel company managed their guest loyalty database on a mainframe computer. Accessing the mainframe directly from large volume web applications did not result in solutions that provided the expected user experience. The new web applications were being supported by a services layer providing access to many of the company’s resources, including those related to loyalty information. However, the services that exposed the loyalty data through the mainframe had inconsistent performance leading to user experience issues within the consuming applications.
The company also had many legacy applications like call center and property management systems that were integrated with the mainframe to maintain loyalty data. They did not have the time or resources to migrate everything away from the mainframe solution to a new loyalty platform. At this time both the company and guests had the expectation that changes to the loyalty records would be propagated within 24 hours of the change.
The assignment was to resolve the user experience and performance problems when accessing data from the mainframe and provide a service-based solution that was highly available and could be used by new systems as they came on-line to access the loyalty data.
The team determined that an MSA was an appropriate solution and carved out a team specifically to develop, maintain, and operate the new loyalty services. A resilient distributed grid database was selected, and service instances and data nodes were designed to work in concert. All parties agreed that the new distributed database accessed via services would become the primary authoritative source of data for loyalty information. Processes were built to daily synchronize the new MSA-based Loyalty System with the mainframe copy. This allowed the existing mainframe connected systems to work as previously without changes.
The new MSA successfully addressed the initial performance concerns. The new solution also provided an easier means of integration with other systems easing the migration of the older systems to the new loyalty solution and reducing the costs and time to market to implement the changes.
Part No.: Part Title
If your document contains major sections covering separate topics, it may be sensible to divide it into parts.
Copy this section to create further parts.
The Part page is derived from the Title page.
Edit the part number (which uses the Part Number style) and part title (which uses the Part Title style) as appropriate.
Part pages would normally appear on
Data is the lynchpin in a good MSA and understanding the interaction and relationship between data and Microservices in and MSA Solution is essential. This guide focuses on the aspects of that that are specific to MSA (it assumes that the practitioner has good understanding of basic data concepts and from SOA perspective). It helps you understand these from lenses, key to MSA, 1> Persistence of Data, and 2> Consistency of Data. It then further develops these in terms of the Capabilities, Patterns that enable the more common Scenarios.
The Use Cases demonstrate how these various aspects come together in a variety of solutions across the industries.
Essential takeaways from this guide are that:
Data Principle: an MSA must be the authoritative source of the data managed by its services. The rationale is that if the MSA is not the authoritative source it is in violation of the independence principle.
All ABBs of the solution must have their level of Resiliency, Availability, and Scalability consistent with MSA to realize the benefits of MSA.
Part No.: Part Title
If your document contains major sections covering separate topics, it may be sensible to divide it into parts.
Copy this section to create further parts.
The Part page is derived from the Title page.
Edit the part number (which uses the Part Number style) and part title (which uses the Part Title style) as appropriate.
Part pages would normally appear on
For chapter headings, use Heading 1. This style always throws a new odd-numbered page.
Copy this section to create further chapters.
Use the Body style for basic paragraph text.
Sample Body text
Within a chapter, use Heading 2, Heading 3, Heading 4, and Unnumbered Heading.
Code examples should appear in constant width font; use the Code Example style.
Sample code example
Sample code example
To insert a footnote, select References/Insert Footnote. The cursor will jump to the footnote field so that you can input text. Use the Footnote Text style.
Sample footnote marker.[2]
Graphics can be incorporated into the document using Insert/Picture.
Add the caption below the figure by selecting Reference/Insert Caption. Use the Caption style.
A colon after the auto-number is preferred. Numbering of figures should be continuous throughout the document.
Figure 1: Sample Figure Caption
The preferred list formats are bullet, Arabic numeric, and variable.
For bullet lists, use the Bullet List style. For sublists below bullets, use the Dashed List style.
For numeric lists, use the Numbered List style. For sublists below numerics, use either the Dashed List style or the Numbered Sublist style.
For variable lists, use the Variable List style. You will need to enter the term followed by a tab. If the term is longer than the tab setting, use Shift+Return to start the following description at the correct indent.
Sample paragraph associated with a bullet list item
Sample variable list term
Sample variable list term definition
To create a note, use the Note style. Enter the text “Note” in Bold followed by a tab, followed by the text of the note.
For multiple notes, use an Unnumbered Heading “Notes” followed by a Numbered List.
Note Sample note (for single notes).
For tables, use the Table Column Heading style for column headings and the Table Text style for the content of the cells.
A single line border is preferred for all cells. The column heading row is shaded at 10% (no color).
For tables that span multiple pages, make sure the Heading Rows Repeat option is selected.
Add the caption before the table by selecting References/Insert Caption. Use the Caption style.
A colon after the auto-number is preferred. Numbering of tables should be continuous throughout the document.
Table Column Heading | Table Column Heading | |
|---|---|---|
Table text | Table text | Table text |
To insert a cross-reference, go to References/Cross-reference.
Try to be consistent in the reference style used. The preferred style is Chapter n, Section n.n.
For Figures and Tables, select Only Label and Number.
References to external documents should be used consistently to avoid confusion. Their full designation should be added to the Referenced Documents section in the front matter.
Part No.: Part Title
If your document contains major sections covering separate topics, it may be sensible to divide it into parts.
Copy this section to create further parts.
The Part page is derived from the Title page.
Edit the part number (which uses the Part Number style) and part title (which uses the Part Title style) as appropriate.
Part pages would normally appear on an odd-numbered page.
Appendices contain material required for reference.
Examples of appendix content are: descriptions of data formats and file structures; input and output codes (e.g., character conversion codes); global processing limitations; sample files, reports, or programs.
For appendix headings, use Heading 1 Appendix. Within an appendix, use Heading 2 Appendix and Unnumbered Heading.
Copy this section to create further appendices.
The glossary contains brief definitions of terms used in the document.
API
Application Programming Interface
API Gateway
A software pattern that resides between clients and services, takes a client request, and provides centralized handling of the API communications that go between the client and the backend services.
Architecture Building Block (ABB)
An ABB is a constituent of the architecture model that describes a single aspect of the overall model. It specifies the required Solution Building Blocks (SBBs) at a more logical (or supplier-independent) level. ABBs are key elements in the creation of an architecture and are produced as a result of the business, information systems, and technology architectural processes.
Solution Building Block (SBB)
An SBB is a candidate solution that conforms to the specification of an Architecture Building Block. SBBs relate to the Solutions Continuum and may be either procured or developed. They represent the physical realization of the ABBs and are typically implemented as projects
Architecture
The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.
Atomic
A fundamental characteristic of ACID database transactions; atomic means that the parts or steps to complete the data changes must all succeed together or must all fail together.
Authoritative Data Source
The primary data record which contains the latest value of a datum, which should be used as the reference for any new copies of that particular data item which are needed by the system.
Container
A standardized unit of software that bundles an application’s code together with the related configuration files and libraries, isolating the application from its runtime environment.
Consistent
A state where replicated data across a number of instances all have the same value. For example if a datum contains the values 1,2,3 and copies currently contain 2,3,5 the data is not consistent across service instances until each service instance contains the value 1,2,3.
Consistent Update
A guarantee or agreement that change to a datum will always be applied against the consistent view of the data
Consistent View
An agreement or guarantee that the value returned from a collection of instances will always be the current value.
Current
A state where an instance has the most recent version or update to a datum
Data Mesh
A decentralized data architecture that organizes data in a business domain-specific manner providing distributed, decentralized ownership of the data and enabling better data access
Datum
A piece of information. Typically a record in a relational database a resource in a RESTful model, or a document in a noSQL data store.
Decoupling
A characteristic of independent microservices, which implies that different microservices are unaware of each other’s functions, and clients have no knowledge of implementation details.
Eventual Consistency
A consistency model used in distributed computing to achieve high availability that informally guarantees that, if no new updates are made to a given data item, eventually all accesses to that item will consistently return the most recently updated value.
Horizontal Partitioning
A table distribution scheme where a table is broken into separate tables across multiple instances with each table containing a subset of the rows (datums) representing the complete set of data.
Inconsistent
A state where the value of data replicated between Service Instances differ between various instances
Instance
A single operating instance of a service, preferred over the term node to avoid ambiguity
Isolated
Changes that occur during one transaction are unaffected by changes initiated by other transactions
Message Bus
A form of Message Queue
Microservice
An individual microservice is a service that is implemented with a single purpose—closely aligned to a specific business capability, which is self-contained, and independent of other instances and services. The microservice is the primary architectural building block of the Microservices Architecture.
Microservices Architecture
An architectural style that structures an application or system as a set of loosely coupled, independent and self-contained services, which align closely with business capabilities.
MSA
1. A Microservices Architecture.
2. A system whose architecture is a microservices architecture.
Persistence
A characteristic of stored data indicating that this data remains unchanged after the system is stopped and restarted, regardless of the medium used to store the data.
Primary Instance
A primary instance is an instance that represents the consistent view guarantee
Queue (or Message Queue)
A form of asynchronous service-to-service communication typically implemented as middleware. Queues store messages – packets of data created by one application intended to be consumed by other applications – and store them, meaning that the sender and receiver of the messages don’t need to interact at the same time
Replication
The process of creating exact copies of data items
Self-Containment
A Microservice is a self-contained, independent deployable unit. A Microservice encompass all external IT resources (e.g., data sources, business rules) necessary to support the unique business activity.
Service Contract
Specification of the function performed by a service, the data produced or ingested by the service, and the protocols and message formats for data exchange
Service Independence
A Microservice is independent of other Microservices or other services. Each of the services is developed, deployed, and evolves independently.
Service Oriented Architecture (SOA)
A software architecture style based on service-orientation; the services are logical representations of repeatable business activities that are self-contained, are a black box to service consumers, and may be composed of other services
Shard
A single subset table or collection of datums in a distributed database. This term is most commonly used for horizontal subsets.
Sharding
The process of dividing a table into shards.
Shard Scheme
The method or algorithm used to determine where a datum will be assigned or stored.
Single Responsibility
Each service is mapped to atomic business activities: Each Microservice is responsible for one business activity.
Stateless
The property of a service whereby it does not store any information relative to the session or transaction history, and will respond identically every time to the same set of inputs. Each request to the service must contain all of the information necessary for completion of that particular service task.
Vertical Partitioning
A table distribution mechanism where a table is divided into multiple tables with each table containing a subset of the columns that represent the complete subset of the data.
The Open Group Guides should include an index.
You should aim to build an index that is concise and useful; i.e., a few well-chosen pointers are more useful than index entries for every instance of a term.
To set a marker for an index entry, highlight the text to appear in the index, select References/Mark Entry, enter data as appropriate and check Mark.
The Index is generated when printing the document. To manually update it, Right-Click on the Index list and select Update Field.
sample index entry 14
Note that the term “consistency” is used in various data processing contexts, which may have different definitions. See for example the definitions at https://www.cs.colostate.edu/~cs551/CourseNotes/Consistency/TypesConsistency.html that apply in the context of distributed operating systems. Our definitions apply in the context of Microservices Architecture. ↑
This is a sample footnote. ↑