Written by Inder Singh
For businesses operating in regulated industries, especially financial services, data sovereignty is no longer just an IT concern. It has become a boardroom-level discussion.
At a basic level, data sovereignty means understanding where your company’s data is stored, processed, and backed up and which country’s laws apply to it. But in practice, it affects far more than the location of a database server. It influences cloud strategy, application design, security controls, deployment processes, monitoring, disaster recovery, and day-to-day engineering operations.
I saw this first-hand while working with a fintech organisation in Qatar.
The company’s online transaction platform was initially hosted on AWS as a monolithic architecture. As the business grew, data governance and local hosting requirements became increasingly important. The decision was made to move the platform to an Azure data centre in Qatar, while also using the migration as an opportunity to modernise the overall technology stack.
Rather than simply moving existing servers from one cloud to another, the application and platform were redesigned with scalability, resilience, and operational control in mind.
Designing the Platform Around Data Requirements
One of the most important lessons was to begin with the data, not the infrastructure.
Before choosing services or designing environments, the team needed clarity on which data could be stored locally, how it could be accessed, how backups would be handled, and what controls were needed for sensitive financial information.
The application was rebuilt around a microservices architecture and deployed using Azure Kubernetes Service (AKS). This gave the engineering team more flexibility to manage individual services independently. Teams could deploy, scale, monitor, and troubleshoot components without unnecessarily affecting the entire platform.
However, Kubernetes alone does not make a platform compliant.
For a regulated financial workload, the surrounding controls matter just as much:
- Where application databases and backups reside
- How services communicate with each other
- Who has access to production environments
- How deployments are approved and tracked
- How incidents, recovery, and failover are managed
The goal was not only to run workloads in Qatar. It was to make sure the entire operational model supported the organisation’s data-governance responsibilities.
Building Resilient Transaction Processing with Kafka
As the transaction platform expanded, it needed to support different payment and transaction-related systems, including EFT and POS environments.
To support this, Apache Kafka became an important part of the architecture.
Kafka allowed different application services to exchange transaction events without tightly coupling every component. Instead of one system waiting directly for another system to complete a task, events could be processed asynchronously where appropriate.
This approach offered practical advantages. If a downstream service experienced a temporary issue, it did not always need to stop the complete transaction flow. Events could be retained and processed once the affected service recovered.
From an operations perspective, this also improved visibility. Engineering teams could better understand how events moved through the platform, identify bottlenecks, and investigate issues affecting transaction processing.
For financial platforms, this kind of visibility is extremely valuable. Reliability is not only about keeping servers online; it is also about understanding what happened to every important transaction.
Database Availability, Consistency, and Recovery
The database layer was designed using a MariaDB Galera Cluster to support clustering and high availability.
Database migration is often one of the most sensitive parts of any cloud-modernisation project. Copying data to a new environment is not enough. Teams must validate replication, failover behaviour, backup integrity, restoration procedures, and transaction consistency.
For fintech systems, data validation and reconciliation are particularly important.
A successful migration should not be measured only by whether the application opens successfully after cutover. It should also demonstrate that critical records remain consistent, transactions are processed correctly, and recovery processes work when required.
This means testing real-world scenarios such as node failures, database recovery, backup restoration, and application behaviour during temporary connectivity issues.
Making Compliance Part of DevOps
The deployment process was built around GitHub-based CI/CD pipelines. This made application and infrastructure changes more controlled, repeatable, and traceable.
For me, this is where data sovereignty and DevOps connect most clearly.
Compliance should not rely only on a manual checklist before a production release. A stronger approach is to build governance into normal engineering workflows. Teams should be able to identify what changed, who approved it, how it was tested, and when it reached production.
Monitoring also formed an important part of the operational model. Using Prometheus and Grafana, the operations team could monitor application health, transaction behaviour, infrastructure performance, and service availability.
This provides visibility beyond CPU, memory, and disk usage. For a transaction platform, it is important to know whether the application is functioning correctly from a business and transaction-processing perspective.
Another important part of securing the environment was centralized identity and Single Sign-On (SSO). Instead of allowing users to maintain separate credentials across different systems, SSO provides a more controlled way to manage access to cloud platforms, Kubernetes environments, CI/CD tools, and other operational systems. Combined with role-based access and proper access reviews, it also makes it easier to control who can access production environments and to maintain a clear audit trail. For regulated environments, centralized identity management can significantly reduce the risks associated with unmanaged or shared credentials.
Three Practical Lessons for Technology Leaders
- Start with data requirements, not cloud services.
Understand where sensitive data is permitted to reside before finalising the platform design. - Treat compliance as an operational discipline.
Access controls, Kubernetes, databases, CI/CD, monitoring, backups, and disaster recovery should all support compliance requirements. - Use migration as an opportunity to modernise.
Moving to a new cloud location can improve architecture, automation, resilience, and observability—not just change the hosting provider.
Final Thoughts
For CEOs and technology leaders, data sovereignty should not be viewed only as a legal, procurement, or hosting requirement. It is an architecture and operations responsibility.
The strongest approach is to design the right controls into the platform from the beginning. When data governance, automation, resilience, monitoring, and access control are part of normal engineering operations, compliance becomes easier to manage and less likely to become a late-stage obstacle.
For a platform handling sensitive financial data, that level of control is not optional; it is part of building long-term trust.
Author Bio:
A seasoned Tech Entrepreneur with 20 years of industry experience in DevOps and Cloud consulting. I specialize in delivering tailored DevOps solutions, with extensive experience working with fintech companies globally. I have successfully implemented DevOps strategies for the fintech, travel, and healthcare industries globally. My expertise spans IT infrastructure, cloud consulting, cybersecurity, migrations, managed services, Kubernetes, and Microservices architecture, all aimed at driving innovation and business success across industries.
As a seasoned IT professional, I specialize in architecting and managing EFT (Electronic Funds Transfer) switch solutions on the Azure cloud platform. With deep expertise in configuring and optimizing EFT systems, I ensure seamless transaction processing, secure data handling, and high availability for financial institutions. Leveraging Azure’s cloud-native capabilities, I implement scalable, resilient, and cost-effective EFT solutions that enhance payment infrastructure performance. My background in cloud architecture, combined with a focus on security and compliance, enables me to deliver reliable and efficient electronic fund transfer services across diverse financial networks.