Observability Architecture: Financial Payments Introduction

Back in September 2020, I was researching open-source architectures - meaning looking at several customer solutions from my employer at the time - and developing a generic view of these solutions for certain use cases.

One of the use cases is known as financial payments. Back in 2020, I kicked off a series covering this architecture with the article Payments Architecture - An Introduction. The series consisted of six articles and covered architectural diagrams from logical and schematic to detailed views of the various use cases we uncovered.

The architectures presented were based on open-source cloud-native technologies, such as containers, microservices, and a Kubernetes-based container platform. The major omission in this series was to avoid discussing any aspect of cloud-native observability.

This series will take a look at fixing that omission with an open-source, standards-based, cloud-native observability platform that helps DevOps teams control the speed, scale, and complexity of a cloud-native world for their financial payments architecture.

The Baseline Architecture

Let's review the use case before we dive into the architectural details. For a bit of background, we review what the base open-source generic architecture was focused on for the financial payments use case.

Cloud technology is changing the way payment services are architected. This series builds on the original baseline solution that was used to modernize payment services. Note that you can find this and other open-source architecture solutions in their repository; feel free to browse them at your leisure. The rest of this article will focus on introducing cloud-native observability to your payments architecture.

These projects are providing you with a way to create a cloud-native payment architecture that's proven to work in multiple customer cloud environments, with a focus in this article on the addition of cloud-native observability.

Now let's look at the use case definition and lay the groundwork for diving into how you can add cloud-native observability to your architecture.

Defining Payments

To start off our story, the following statement has been developed to help in guiding our architecture focus for this financial payments use case: 

Financial institutions enable customers with fast, easy-to-use, and safe payment services available anytime, anywhere.

With this guiding principle, the baseline architecture was developed to help everyone to be successful in providing their customers with a robust payment experience. We continue to expand on this baseline adding a robust cloud-native observability platform that provides the control, visibility, speed, and scale that financial service providers are looking for.

All diagrams and components used to expand the architecture with cloud-native observability conform to the original design guidelines and leverage the same diagram tooling. We'll start by revisiting the original logical diagram and sharing insights into the additional (newer) components related to the cloud-native observability architecture. You'll discover the technologies used to collect and store both metrics and tracing data through the use of a collector and the Chronosphere platform.

This is followed by specific examples worked out in schematic diagrams (physical architecture) that explore a few specific financial payments use case examples and provide you with guides for mapping cloud-native observability components to your own existing architectures. You'll see both networked connections and data flow examples worked out to help you in your understanding of the generic views being provided.

Next, let's quickly cover how you can make use of the content in this financial payments project and leverage both the ability to download images of the architectures and to be able to open the diagrams in the open-source tooling for adjustment to your own needs.

Using the Payments Project

The architecture collection provided insights into all manner of use cases and industries researched between 2019-2022. The architectures each provide a collection of images for each diagram element as well as the entire project as a whole, for you to make use of as you see fit.

If we look at the financial payments project, you'll see a table of contents allowing you to jump directly to the topic or use case that interests you the most. You can also just scroll down through each section and explore at your leisure.

Each section provides a short description covering what you see, how it's important to the specific payment topic listed, and a walk through the diagram(s) presented. You can download any of the images to make use in any way you like. At the bottom of the page, you will find a section titled Download Diagrams. If you click on the Open Diagrams link, it will open all the available logical, schematic, and detailed diagrams in the diagram tooling we used to create them. This makes them readily available for any modifications you might see fit to make for use in your own architectures, so feel free to use and modify!

Finally, there is a free online beginners guide workshop available focused on using diagram tooling, please explore to learn tips and tricks from the experts.

Series Overview

The following overview of this o11y architecture series on adding cloud-native observability to your financial payments architecture can be found here:

• Financial payments introduction (this article)
• Financial payments logical observability elements 
• Adding observability to immediate payments example
• Adding observability to financial calculations example

Catch up on any articles you missed by following one of the links above as the series progresses. Next in this series, explore the cloud-native observability elements needed for any financial payment processing architecture.