Federated Governance for Distributed Data Systems

Federated data discovery and access is the ability to find and use data across distributed databases while each location keeps local ownership and control. Unified discovery depends on knowing where each partition or replica lives, which direction data flows between locations, and whether reads return the latest consistent state. Access control and auditability depend on the same facts: who can write in each location, how changes propagate, and how lineage is preserved in order.

1.1Distribution Models and Deployment Locations

Distribution models and deployment locations define the failure and location boundaries that federated discovery must expose to users. Multi-instance sharding (opens in a new tab) manages disjoint partitions where a separate database instance manages each partition, and more shards can be added dynamically over time for scalability, but cross-shard queries might not be possible in all systems. Bidirectional replication with conflict resolution permits concurrent updates to the same data item in different instances, which leads to an inconsistent state until a conflict resolution policy decides the last consistent state. Cloud and partner-managed databases add location boundaries that determine whether data stays discoverable during an outage:

• Zonal system is tied to a zone and is available when the zone is available, but is inaccessible if the zone becomes unavailable.
• Regional system is tied to a region and is accessible when at least one zone is accessible, even if any combination of other zones becomes inaccessible.
• Cross-regional system is tied to two or more regions and functions properly when at least one region is available, and can support a cross-cloud system if the database can be installed in all intended clouds.

A regional system might share a disk between two zones so the database continues in the remaining zone if either zone fails, but the database is unavailable if both zones fail even when other zones remain online. Discovery metadata must therefore record the system scope, because a zonal, regional, or cross-regional scope decides whether data remains discoverable and accessible during a zone or region outage.

1.2Deployment Patterns That Shape Discovery and Access

Deployment patterns define how data flows from source databases to destination databases and what a reader will see in each location. Asynchronous unidirectional replication uses a primary database that replicates to one or more secondary databases, where the secondary can be used for read access but the application must factor in replication lag. Bidirectional replication with conflict resolution uses two primary databases that replicate asynchronously to each other through two independent replications, so a write-write conflict can arise if the same data item is changed concurrently in both locations. Fully active-active synchronized distributed system uses a single distributed database in a primary-primary setup where an update in any primary is transactionally consistent and synchronously replicated, so each application always accesses the last consistent state without delay or conflict risk.

The four patterns compare directly for federated access decisions:

1.3How Applications Access Data Across Clouds

Application placement decides whether federated access crosses a network boundary on every request or stays local to each deployment location. In a primary location deployment for cloud bursting, the database lives only in the primary location and the bursting application in the standby location accesses the database in the primary location across locations. In a primary and standby location deployment, a database instance lives in both locations and each location's application service instances access the local instance, with the two databases transactionally synchronized or asynchronously synchronized with possible delay. If updates occur in the standby location, those updates must propagate back to the primary location, and concurrent updates in both locations require conflict resolution.

Best-in-class use across clouds, where business logic runs in one cloud and analytics runs in another, exposes the same tradeoff in three data-management options. Partitioned data gives each part of the application its own separate database partition with no direct connection, so the managing application writes shared data twice to make it available in both partitions. Asynchronously replicated databases flow data from the business application database in one cloud to the analytics database in the other cloud, which fits when the analytics side needs the same dataset or a subset. Transactionally synchronized databases act as a single distributed database where each update from each application is immediately and consistently available to both partitions. For distributed services deployed in two or more locations, the transactionally synchronized option is the best fit for running service instances in all locations, while asynchronous replication leaves the risk that the same item is modified concurrently and requires a resolution strategy that can sometimes need manual intervention.

1.4Consistency and Conflict Handling for Trustworthy Discovery

Consistency controls whether federated discovery returns data that users can trust for decisions. Partitioned datasets stored in the same database remain completely separate, so a change to one dataset does not cause changes in another, and two applications can share one database while seeing isolated views. Asynchronous replication preserves availability for reads but introduces lag, so discovery results from a secondary may not reflect the latest primary write. Bidirectional replication adds write-write conflict risk on the same primary key, so replication must include resolution logic that determines the last state during replication.

Networking assumptions bound these guarantees across clouds. The model assumes a secure network connection exists between clouds and that databases and their components can communicate with each other. From a functional perspective networking generally has no effect on correctness, but throughput and latency of the network can affect database latency and throughput. Federated access policies must therefore combine the replication pattern with network reality: allow local reads from secondaries when lag is acceptable, and route reads requiring strong consistency to a primary or to a transactionally synchronized replica.

1.5Change Capture and Migration Consistency for Lineage and Audit

Change capture and migration consistency provide the reliable lineage and audit trail that federated discovery depends on. Change data capture (CDC) (opens in a new tab) based on a transaction log reads the database transaction log continuously, such as the binary log in MySQL, so every insert, update, and delete is observed in order and migrated to the target without loss and with the least load impact. Differential querying polls data through the query interface using a timestamp or sequence number added to each item, records the current time or sequence number in its internal state, and passes changes onward, but deletes require special design through a logical delete flag or separate delete tables because a deleted row cannot be detected by polling. CDC is the preferred approach because differential querying needs schema changes and adds query load unrelated to client logic.

Migration consistency defines the audit expectation that source and target states are equivalent after movement. Complete means all specified data is actually migrated, duplicate-free means each piece is migrated once and only once, and ordered means source changes are applied to the target in the same order they occurred. Active-passive migration allows writes only in source databases while targets allow read-only access, while active-active migration allows clients to write into both source and target databases and requires conflict resolution rules for every semantic conflict or inconsistency results. A database migration system invokes interfaces of all source and target databases across on-premises and cloud environments, extracts from sources like DB1 and DB2, transports to targets like DB3 and Spanner, and optionally transforms data in transit, with independent migration processes able to run sequentially or concurrently.

Cross-system policy enforcement is the practice of defining security, privacy, and compliance rules once at the center and having them apply automatically across every distributed data product. The self-service data infrastructure platform team builds the shared components and guardrails, while distributed domain teams build data products on top of them under a shared responsibility model. Even when a domain team uses its own infrastructure, that infrastructure must still comply with organization-wide policies for security and data governance.

2.1Central Ownership and Shared Responsibility

Central ownership and shared responsibility divide work between the self-service data infrastructure platform team (opens in a new tab) and distributed domain teams. The platform team creates reusable infrastructure for ingestion, storage, processing, and consumption, embeds governance into templates and blueprints, and publishes best practices that reduce cognitive load for domain teams. Domain teams remain responsible for their data products, but the platform team defines what it supports, releases features on a prioritized roadmap, and co-invests or embeds engineers when domain-built infrastructure is strategically important so it can be repackaged for reuse.

This model requires an explicit tradeoff between autonomy and standardization. Limiting domain teams to a small set of approved options in the early stages can speed approval and adoption, but too much centralization creates a bottleneck at the platform team that prevents scaling. The goal is not an ungoverned landscape or a fully locked-down platform, but consistent compliance where producers choose from constrained, pre-governed options and any deviation still inherits global observability, instrumentation, and compliance automation.

2.2From Central Definition to Automated Enforcement

Automated enforcement turns central policy definitions into metadata that systems can evaluate without manual review. The platform team builds tooling to automate metadata annotations of data products and to support policy creation and verification, and the data governance engineer extends that tooling for use by all data domains. Annotations travel with the data product from the domain that produces it to every system that stores, processes, or consumes it, so the same policy decision is applied consistently across boundaries.

Enforcement follows an ordered flow from definition to detection:

1. Annotate: Tools auto-generate governance annotations that describe sensitivity, ownership, and handling requirements for each data product.
2. Enforce: Policy engines evaluate the annotations at access and deployment time to allow, deny, encrypt, or mask data across storage and processing systems.
3. Verify and alert: Monitoring continuously checks annotation consistency, automatically verifies compliance, and raises alerts, reports, and dashboards when a product violates policy so violations are detected in a timely fashion.

Because verification depends on annotation quality, inconsistent or missing annotations break enforcement downstream. That dependency is why monitoring checks consistency itself, not only final violations.

2.3Identity, Access, and Network Boundaries

Identity, access, and network controls establish who can reach data and from where, with the trust boundary drawn between public networks and private data systems. Central policies restrict public access to BigQuery datasets and Cloud Storage buckets, enforce public access prevention by default, and require uniform bucket-level access on Cloud Storage buckets so Identity and Access Management (IAM) is the single access control plane instead of mixed bucket and object ACLs. Least-privilege controls narrow standing access further by requiring least-privilege service accounts for Google Kubernetes Engine (GKE) clusters and by restricting Firestore and Datastore roles to only the Firestore service agent (*@gcp-sa-firestore.iam.gserviceaccount.com).

Network boundary policies apply the same central intent to connectivity:

• Block public IP addresses for AlloyDB cluster instances and restrict public IP addresses on Compute Engine instances through the compute.vmExternalIpAccess organization policy constraint.
• Skip creation of the default network with the compute.skipDefaultNetworkCreation constraint so new projects do not inherit an overly open network.
• Require TLS 1.2 or higher and restrict legacy TLS versions so data in transit between systems uses a minimum encryption standard.

Traffic therefore flows only from authorized identities through private or explicitly allowed network paths to governed resources, and any grant outside that path is flagged as excessive or noncompliant.

2.4Encryption and Key Governance

Encryption governance ensures sensitive data is protected throughout its lifecycle with customer-controlled keys. Central controls require encryption of data at rest with customer-managed encryption keys (CMEK), enforce CMEK for supported services, and restrict non-CMEK services so workloads cannot run where central key control is unavailable. Key governance depends on Cloud Key Management Service (KMS), where policies define the crypto key protection level, encrypt-decrypt purpose, key version algorithm, and rotation, including asymmetric key creation and management for transfer protection.

Two complementary organization policies control where keys live and how they are used. The requirement to use CMEK establishes that a governed key must protect the resource, while the gcp.restrictCmekCryptoKeyProjects constraint restricts which projects may supply KMS CryptoKeys for CMEK. Together they enforce that encryption flows from an approved key project to the data resource, preventing a domain team from satisfying the encryption check with a key outside central custody.

2.5Retention, Disposal, and Geographic Controls

Lifecycle controls enforce how long data is kept, how it is removed, and where it is allowed to flow. Central definitions include retention periods for Cloud Storage buckets, locked bucket retention policies that cannot be reduced, object versioning to preserve history, retention of audit records, and storage-class lifecycle actions that move or delete objects according to business and legal requirements. Secure disposal requires methods where data is not recoverable by forensic means, while privacy-by-design defaults require restrictive sharing settings from creation.

The same lifecycle intent extends across jurisdictions through data-security posture controls. The Restrict Flow of Sensitive Data Across Geographic Jurisdictions control flags access from outside an approved list, using the allowedRegions parameter to define which regions clients may access supported data stores from. If allowedRegions is empty, all access is flagged as a violation, so data flows only from an allowed region to the governed store and any cross-boundary access must be explicitly permitted by updating the control parameter.

2.6Continuous Verification and Remediation

Continuous verification proves that centrally defined policies remain enforced as distributed systems change. Controls operate in Audit and Detective enforcement modes and report findings to Security Command Center (opens in a new tab), with attributes that include severity such as MEDIUM or HIGH, finding category such as SKIP_DEFAULT_NETWORK_CREATION_ORG_POLICY or DATA_SECURITY_POSTURE_FLOW_VIOLATION, revision number, supported tiers, and supported target resources of organization, folder, and project. Enabling services such as Cloud Asset Inventory, bucket logging, firewall rule logging, continuous network traffic monitoring, and database flag logging provides the evidence those detectors evaluate.

Remediation closes the loop from detection back to central definition. When a finding fires, the owner updates the corresponding organization policy constraint, IAM grant, or resource configuration — for example, setting constraints/compute.skipDefaultNetworkCreation to true, removing excessive Firestore role grants, or adding a region to allowedRegions — and validates the change in build and deployment processes with tools such as Binary Authorization (opens in a new tab). This cycle keeps distributed enforcement aligned: central teams own the policy definition and detection logic, domain teams own fixing their resources, and dashboards and alerts keep the status of every data product visible across the organization.

Establishing data domains and ownership structures means dividing distributed data into clear partitions with a designated owner that can write and manage each partition. In multicloud database design, a domain is a partition, shard, or separate database that one application or location owns, while replication and deployment boundaries define how domains interact. Decentralized management works when each domain can evolve independently, with explicit rules for sharing, replication, and conflict handling.

3.1Partitioned Domains and Sharding

Partitioned domains and sharding define ownership by giving each part of an application its own separate data partition. A partitioned database (opens in a new tab) is a data domain design where each part of an application owns a separate partition and no database is directly connected to another. Partitioning can be implemented as two applications sharing a single database that contains completely separate datasets, where a change to one dataset does not cause changes in another, or as each application part owning its own database partition. In the separate-database case, the owning application writes any data that must exist in both partitions twice, so ownership and write responsibility stay with the producer.

Multi-instance sharding extends partitioning for scale by assigning each disjoint partition to a separate database instance. More shards can be added dynamically over time, which makes the domain model scalable as data grows. The tradeoff is that cross-shard queries might not be possible because not all systems support that functionality, so domain boundaries must align with query patterns.

3.2Deployment Boundaries That Shape Ownership

Deployment boundaries define the failure and management scope that a data domain depends on, which directly shapes who can own and operate it. A zonal system is tied to a zone and is available only when that zone is available; if the zone becomes unavailable, the database cannot be accessed. A regional system is tied to a region and remains accessible when at least one zone is accessible, while a cross-regional system is tied to two or more regions and functions properly when at least one region is available.

These boundaries determine how decentralized ownership can be. A zonal domain concentrates ownership in one zone but creates a single point of failure, while regional and cross-regional domains allow ownership to survive zone or region loss. A regional system may share a disk between two zones so it can continue in the remaining zone if either zone fails, but it becomes unavailable if both of those zones fail even when other zones remain online.

3.3Write Ownership Across Replication Patterns

Write ownership defines which domains can modify data, and the replication pattern enforces that ownership through how updates flow from source to destination. A primary database replicates data to one or more secondary databases in one direction, while bidirectional designs allow writes in both locations and require rules for concurrent changes.

The four deployment patterns divide write ownership and consistency as follows:

Choose partitioned ownership when domains must evolve independently without cross-domain effects. Choose unidirectional replication when one domain owns the system of record and another needs read access, such as analytics. Choose bidirectional or active-active only when multiple locations must accept writes, accepting either conflict-resolution logic or the cost of synchronous coordination.

3.4Reshaping Domains Through Migration Cardinality

Migration cardinality is the mechanism for reshaping data domains when ownership needs to consolidate or split to match organizational structure. A direct 1:1 mapping migrates one source database to one target database without changing boundaries, while other cardinalities redesign ownership:

• Consolidation (n:1): data flows from several source databases into a smaller number of target databases to simplify management or use a more scalable target.
• Distribution (1:n): data flows from one centralized source database into several target databases, such as splitting regional data into regional targets with separate owners.
• Re-distribution (n:m): data flows from several source databases into several target databases, such as evenly redistributing unevenly sized shards across new shard owners.

During reshaping, active-passive migration keeps write ownership centralized by allowing modifications only in source databases while target databases allow read-only access. Active-active (opens in a new tab) migration decentralizes write ownership during the move by allowing clients to write into both source and target databases, but then all data conflicts must be resolvable by conflict resolution rules or data inconsistency will result.

Key Facts

• Federated discovery must record whether a system is zonal, regional, or cross-regional because that scope decides whether data stays accessible during a zone or region outage.
• Asynchronous unidirectional replication flows writes from a primary database to a secondary database where reads may lag, while a fully active-active synchronized system synchronously replicates every committed write so both locations see the same state immediately.
• Change data capture (CDC) reads the database transaction log continuously to capture every change in order without loss, while differential querying polls through the query interface and cannot detect deletes without special design.
• Central policy enforcement flows from automated annotation of data products to policy evaluation at access time to continuous verification, and inconsistent annotations break enforcement downstream.
• Customer-managed encryption keys (CMEK) enforcement requires that a customer-managed key protects the resource, while the restrict CMEK key projects constraint controls which projects may supply that key.