# Global table

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/global-table

## Quick definition

A global table is like having a copy of your data in several places around the world at the same time. When you update the data in one region, the change is automatically sent to all the other copies. This helps applications run faster for users everywhere and keeps the data safe even if one region has an outage.

## Simple meaning

Imagine you keep a notebook with your homework schedule. If you only keep that notebook at home, you cannot check your assignments when you are at school or at your friend’s house. A global table is like having identical copies of that notebook in your bedroom, your backpack, and your friend’s house. Whenever you write a new assignment in any copy, the other copies are updated automatically. This means you can always see the latest schedule no matter where you are.

In the world of IT, a global table is a database table that is stored in multiple data centers located in different parts of the world. Each copy is called a replica. When your application writes new information to the table in one region, that change is replicated (copied) to all the other regions. The replication happens very quickly, often within seconds, so every copy stays up to date.

This is extremely useful for applications that serve users all over the globe. For example, a social media app might store user profiles in a global table. A user in Japan can update their profile picture, and that change appears immediately to their friends in Brazil because the Brazilian copy of the table was updated from the Japan copy. Without a global table, the Brazilian users might see an old profile picture until the change is manually copied or until a slower batch process runs.

Global tables also provide high availability. If one region experiences a power outage or network failure, the application can automatically switch to reading from a copy in another region. Users may not even notice there was a problem because the data is still accessible from elsewhere. This makes global tables a key building block for reliable, worldwide applications.

## Technical definition

A global table is a distributed database table that spans multiple geographic regions, implementing multi-master replication to keep replicas consistent. In cloud database services like Amazon DynamoDB Global Tables or Google Cloud Spanner, a global table is defined with a primary key and optionally secondary indexes, and the service automatically handles asynchronous replication of all write operations across the configured regions.

The core mechanism behind a global table is conflict-free replicated data types (CRDTs) or last-writer-wins (LWW) conflict resolution. When two writes occur simultaneously in different regions on the same item, the system uses a timestamp-based approach to determine which write is considered the latest. This ensures that all replicas eventually converge to the same state, a property known as eventual consistency. However, most global table implementations also offer strong consistency for reads within a single region, meaning that after a write is acknowledged locally, any subsequent read in that same region will see the new data.

For exam purposes, you need to understand the concept of replication latency. Replication from one region to another typically takes less than one second, but it can vary based on network distance and load. This is important when designing applications that require immediate global consistency. For example, if a user buys a concert ticket in London, the ticket inventory should be updated globally very quickly to prevent overselling. Global tables are often combined with application-level logic, such as distributed locking or conditional writes, to handle such scenarios.

From a standards perspective, global tables rely on distributed consensus protocols like Paxos or Raft for metadata management, but the actual data replication may use simpler approaches. In Amazon DynamoDB Global Tables, the replication is based on stream processing, each table change is written to a change stream (DynamoDB Streams), and a service reads that stream and writes the change to replicas in other regions. In Google Cloud Spanner, the entire database is globally distributed with synchronous replication using TrueTime, giving strong consistency across regions.

Real IT implementation considerations include choosing the right primary key to avoid hotspots, managing cross-region write costs (since each write is replicated to every region), and monitoring replication lag. For disaster recovery, global tables can serve as a multi-region active-active solution where traffic is load-balanced across regions, or as an active-passive setup where one region is primary and others are read-only until a failover is needed. Security is also handled regionally, each replica inherits the access control and encryption settings of its parent region, so you need to apply consistent policies across all regions.

## Real-life example

Think about a chain of coffee shops called BrewAround, which has stores in New York, London, Tokyo, and Sydney. BrewAround has a loyalty program where customers earn points that can be redeemed in any store. The customer database is stored as a global table.

Now imagine Maria, a customer who lives in New York but travels frequently. She buys a coffee in New York and earns 10 points. The barista swipes her card, and the local system adds the points to her account. But because this is a global table, that update is replicated instantly to the London, Tokyo, and Sydney databases as well.

The next day, Maria stops in London on a layover. She uses her loyalty card again to buy a pastry. The London store’s system reads her profile from its local copy of the global table. It sees the 10 points from New York, adds the 5 points from this purchase, and updates the record. That change then gets replicated back to New York and the other regions. No matter where Maria goes, every BrewAround store sees the most up-to-date point balance.

Without a global table, the London store might have read an older copy of Maria’s points (say, from before her New York purchase) or might have needed to make a slow network call to the New York database. The global table eliminates those delays and ensures a seamless customer experience worldwide. It’s exactly how large-scale services like airline reservation systems or online retail inventories work, they cannot afford to have different data in different cities.

## Why it matters

Global tables matter because they solve a fundamental problem for modern applications: data must be available and consistent across the globe. Users expect fast response times regardless of their location, and they expect that if they update information (like their mailing address or an order status), that change should be reflected everywhere immediately. Global tables provide this capability without requiring the application developer to write complex replication logic.

From a practical IT perspective, global tables improve disaster recovery. If one entire cloud region goes down, the application can continue serving users from another region because a copy of the data exists there. This is a key requirement for many compliance frameworks (like HIPAA or PCI-DSS) that mandate geographic redundancy to protect against outages. Without a global table, you would need to implement manual database replication, deal with failover scripts, and risk data loss if the primary region fails before a backup is taken.

Global tables also reduce latency. When a user in Australia accesses an application whose database is only in the United States, every database query must cross the Pacific Ocean, introducing delays of 200–300 milliseconds. With a global table, there is a local copy in Australia, so queries take only 1–5 milliseconds. This dramatically improves user experience, especially for applications that require real-time interactions like online gaming, financial trading, or collaborative document editing.

Cost is another practical factor. Global tables usually have higher storage and write costs because data is stored in multiple regions and each write triggers cross-region data transfer. However, they can actually lower overall costs by reducing the need for complex application-level caching layers and manual synchronization jobs. For many enterprises, the trade-off is worth the simplicity and reliability that global tables offer.

## Why it matters in exams

Global tables are a topic that appears in several major cloud certification exams, including the AWS Certified Solutions Architect, AWS Certified Developer, Google Cloud Professional Data Engineer, and Google Cloud Professional Cloud Architect. While the concept itself is not too advanced, exam questions often test your understanding of trade-offs: consistency versus latency, cost versus availability, and active-active versus active-passive architectures.

In the AWS Solutions Architect exam, you might see a scenario where a company has users in the US and Europe, and they are experiencing high latency when reading and writing data to a single DynamoDB table in the US. The correct answer often involves enabling DynamoDB Global Tables, which replicates the table to a European region. The exam might also ask about the behavior of global tables during write conflicts. For example, if two users update the same item at the same time in different regions, the last-writer-wins setting determines which write survives. You should know that DynamoDB Global Tables use “last writer wins” based on timestamps, and that you can design your application to avoid conflicts by using unique keys.

In Google Cloud exams, global tables are discussed in the context of Cloud Spanner, which is a globally distributed relational database. Questions might focus on how Spanner achieves strong consistency across regions using TrueTime. You may need to compare Spanner’s synchronous replication with DynamoDB’s asynchronous replication.

For general IT certifications, such as CompTIA Cloud+ or the Certified Cloud Professional, global tables are covered under the domain of storage and databases. Questions might be more conceptual, like asking you to define a global table or to identify a use case. For example: “A multinational e-commerce platform needs to ensure that product inventory is consistent across all regions as quickly as possible. Which database feature should they use?” The answer is a global table.

When studying for these exams, pay attention to the key characteristics of each cloud provider’s global table offering, especially consistency models, replication latency, and conflict resolution. Most exam questions are scenario-based and require you to apply these concepts rather than just recall definitions.

## How it appears in exam questions

Exam questions about global tables typically fall into three categories: scenario-based, configuration-based, and troubleshooting-based.

Scenario-based questions describe a business requirement and ask you to choose the correct technology. For example: “A travel booking website has users worldwide and wants to provide fast read and write access to booking data from any region. The data must be eventually consistent globally but strongly consistent within a region. Which database feature should they use?” The correct answer is a global table or a globally distributed database. Another common scenario: “A financial application must ensure that when a user transfers money between accounts, the balance update is immediately visible to all subsequent reads, no matter the user’s location.” Here you might need to rule out global tables (which are eventually consistent globally) and choose a solution that offers strong consistency, like Google Cloud Spanner or a single-region database with application-level locking.

Configuration-based questions may ask about settings. For instance: “You are creating an Amazon DynamoDB Global Table with replicas in us-east-1 and eu-west-1. What must you enable on the table in us-east-1 before creating the replica?” The answer is DynamoDB Streams. Another configuration question: “In a DynamoDB Global Table, what determines which write survives when two updates happen simultaneously on the same item?” Answer: The timestamp of the write operation – the later timestamp wins.

Troubleshooting-style questions present a problem and ask you to diagnose it. For example: “After enabling DynamoDB Global Tables, developers report that reads in the secondary region occasionally show stale data, even though writes completed in the primary region several seconds ago.” The correct understanding is that eventual consistency means there is a replication lag, and the solution is to either wait longer or implement application-level logic to verify consistency. Another troubleshooting scenario: “A company notices high write costs after enabling a global table with ten replicas.” The issue is that every write is replicated to all ten regions, so you should consider reducing the number of replicas or evaluating whether all replicas are truly needed.

Some exam questions also ask about the required conditions for creating a global table. For instance, you might be asked which AWS services cannot be used together with global tables (like DynamoDB Accelerator (DAX) for a global table, which is not directly supported).

## Example scenario

MediaFlix is a global streaming service that wants to allow users to pause a video on their TV in one country and resume watching on their phone in another country. The watch progress for each user is stored in a global table.

When Maria pauses a movie at home in Canada, her watch progress (say, 45 minutes and 30 seconds) is written to the global table replica in the Canada (Central) region. The global table then automatically replicates that update to replicas in the United States (Northern Virginia), Europe (Ireland), and Asia Pacific (Tokyo). The replication is typically complete within a second or two.

The next morning, Maria is on a flight to Tokyo. After landing, she opens the MediaFlix app on her phone. The app reads her watch progress from the global table replica in Tokyo. Because the replication already completed, the app shows that she paused at 45 minutes and 30 seconds. Without the global table, the Tokyo replica might have shown an older progress (maybe from a previous session), or the app would have had to make a slow query to the Canada database, causing a noticeable delay.

Now consider what happens if Maria had paused the movie again in Tokyo at the same time her friend in Canada tried to update the same progress entry (for instance, if they share an account). The global table uses last-writer-wins based on timestamps. The write with the later timestamp wins, and the earlier write is silently discarded. This is not a problem for a simple numeric progress value, but for applications like collaborative editing, you would need a different mechanism (like CRDTs) to merge changes properly.

This scenario illustrates why global tables are essential for global applications, they provide low-latency data access everywhere, automatic replication, and a simple programming model for developers.

## Common mistakes

- **Mistake:** Thinking that a global table provides immediate strong consistency across all regions.
  - Why it is wrong: Most global table implementations (like DynamoDB Global Tables) use eventual consistency. There is a replication delay, so a write in one region is not instantly visible in another region.
  - Fix: Understand that global tables guarantee eventual consistency globally. For strongly consistent reads, you must read from the region where the write was performed, or use a database that offers global strong consistency (like Cloud Spanner) at higher complexity.
- **Mistake:** Assuming that all cloud providers' global tables work the same way.
  - Why it is wrong: AWS DynamoDB Global Tables use asynchronous replication and last-writer-wins. Google Cloud Spanner uses synchronous replication with TrueTime for strong consistency. The implementation details differ significantly.
  - Fix: Study each provider's specific documentation and understand the consistency model, conflict resolution, and latency characteristics.
- **Mistake:** Believing that adding more regions to a global table always improves performance.
  - Why it is wrong: Adding more regions increases the number of replicas, which increases the cost of writes (each write is replicated to every region) and can also increase replication latency slightly due to network overhead.
  - Fix: Add regions only where you have significant user traffic. Monitor replication lag and cost, and consider using a regional table plus a caching layer instead of a global table for read-heavy, write-light workloads.
- **Mistake:** Thinking a global table can be created without enabling change streams or streams first.
  - Why it is wrong: For DynamoDB Global Tables, you must enable DynamoDB Streams on the source table. The replication mechanism relies on reading the stream of changes. Without streams, the global table cannot be created.
  - Fix: Before adding a replica, verify that the source table has streams enabled and that the stream contains the data you need (keys and old/new images).

## Exam trap

{"trap":"An exam scenario describes a global application requiring instant consistency across all users regardless of location, and the correct answer is a global table.","why_learners_choose_it":"Learners see 'global' and 'low latency' and assume it provides strong consistency everywhere, because that is what the user intuitively wants.","how_to_avoid_it":"Remember that most global tables are eventually consistent across regions. If the question explicitly says 'immediate consistency' or 'strong consistency globally', then a global table is usually the wrong answer. Instead, consider a database designed for global strong consistency (like Google Cloud Spanner) or a single-region database with distributed application logic."}

## Commonly confused with

- **Global table vs Global secondary index:** A global secondary index is an alternate way to query data in a single table, using a different partition key and sort key. It does not replicate data across regions. A global table replicates the entire table (including all indexes) across regions. The names are similar but the purpose is entirely different. (Example: You have a Users table in one region. A global secondary index lets you search users by email instead of user ID. A global table would copy the entire Users table to another region.)
- **Global table vs Database replication (traditional):** Traditional database replication (e.g., MySQL read replicas) often uses a primary-secondary model where only the primary accepts writes. A global table supports multi-master writes (any region can write) and automatically resolves conflicts. Traditional replication typically requires manual failover and can have downtime. (Example: With a traditional read replica, you can only read from the replica; writes go to the primary. With a global table, you can write to any replica and the change propagates everywhere.)
- **Global table vs Multi-region active-passive setup:** In an active-passive setup, one region holds the primary database, and secondary regions hold read-only copies. If the primary fails, you fail over to a secondary. A global table is typically active-active, every region is writable. Some people confuse global tables with passive replicas because both involve multiple regions. (Example: Using a global table is like having three stores where you can both read and write. Active-passive is like having one main store and two backup stores that are for reading only until the main store closes.)
- **Global table vs Distributed database (single system, not global):** A distributed database spreads data across multiple nodes within a single data center or region, often for performance or fault tolerance. It does not span continents. A global table is specifically designed for geographic distribution across multiple regions. (Example: A distributed database might split a big table across 10 servers in one building. A global table would put copies of the table in New York, London, and Tokyo.)

## Step-by-step breakdown

1. **Create the source table** — Start by creating a standard database table in one region. You must define the primary key (partition key and sort key if needed) and any secondary indexes. This table will be the foundation for the global table.
2. **Enable change capture** — For services like DynamoDB, you enable DynamoDB Streams on the source table. This records every write (insert, update, delete) as an event in a stream. The replication process reads this stream to know what changes to copy.
3. **Add replica regions** — In the management console or via API, you specify additional AWS regions where you want copies of the table. The service then creates an identical table structure in each specified region and starts replicating the current data.
4. **Initial data sync** — During the first replication, the service copies the entire source table to each new replica. This can take time depending on the table size and network bandwidth. All existing data becomes available in the new regions.
5. **Continuous incremental replication** — After the initial sync, the service continuously monitors the change stream on the source table. Each new write is sent to all replicas, typically within seconds. The replication is asynchronous, so there is a small delay.
6. **Conflict resolution** — If two writes happen on the same item in different regions at nearly the same time, the service uses a conflict resolution strategy. For DynamoDB, it uses last-writer-wins based on the timestamp of the write. The update with the later timestamp overwrites the other. The loser write is not merged and may be lost.
7. **Read and write from any replica** — Once the global table is active, applications can read and write to any replica. Reads are served locally from the nearest region, providing low latency. Writes are accepted locally and then propagated to all other regions.

## Practical mini-lesson

In practice, setting up a global table requires careful planning beyond just clicking a button. First, you need to assess your data access patterns. If most writes come from a single region, you might want to make that region the primary and use other regions for reads only, this reduces conflict risks. However, if you need low-latency writes from many regions, an active-active global table is the right choice, but you must design your application to handle eventual consistency and potential conflicts.

When configuring a global table, pay attention to the partition key. Because writes are replicated to all regions, a hot partition (one that receives many writes) can cause replication lag and throttle. Choose a partition key that distributes writes evenly. Similarly, consider the size of each item, larger items take more time and bandwidth to replicate.

Cost management is critical. Each write to a global table is replicated to every replica region, so a write that costs 1 write unit in a single table effectively costs N write units (where N is the number of regions) when using a global table. There are cross-region data transfer fees. For read-heavy applications, you can reduce costs by using read replicas in other regions instead of a full global table. But if you need write capability everywhere, the global table is the only option.

Monitoring replication lag is essential for production systems. Most cloud providers offer metrics like “ReplicationLatency” which shows the delay between a write in one region and its appearance in another. If the lag increases, you may need to investigate network issues, throttling, or a partition key hot spot. You should also set up alarms for when replication lag exceeds a threshold (e.g., 5 seconds).

When it comes to security, each replica region inherits the encryption and access control settings of the table. However, you must apply the same AWS Identity and Access Management (IAM) policies and encryption keys (like AWS KMS) in each region, as they are separate instances. For example, if you use a customer-managed KMS key in us-east-1, you need a key with the same alias in eu-west-1, or use an AWS managed key that is region-specific.

Finally, global tables are not suitable for all workloads. Applications that require strong consistency across regions (like financial transactions where double-spending is not acceptable) should not use eventually consistent global tables. Instead, use a globally consistent database like Cloud Spanner or implement distributed locking externally.

## Memory tip

Think “Global Table = Local Speed, Global Reach”, data is written locally but replicated worldwide.

## FAQ

**Can I use a global table for an application that needs strong consistency across all regions?**

No, not for most cloud providers. Amazon DynamoDB Global Tables and similar offerings provide eventual consistency across regions. For strong global consistency, you would need a database like Google Cloud Spanner.

**Does a global table replicate all data, including indexes?**

Yes, global tables replicate the entire table schema, including local and global secondary indexes. The indexes are also maintained in each replica region.

**How long does it take for a write to be replicated to all regions?**

Typically under one second for DynamoDB Global Tables, but it can take longer depending on network conditions, table size, and write traffic. There is no guarantee of a specific time limit.

**What happens if I delete a replica region from a global table?**

The replica and its data are deleted. Any writes that were happening only in that region are lost. It is recommended to first drain traffic from that region before removing it.

**Can I disable writes in a specific replica region?**

No, in a true global table all replicas are writable. If you need a read-only copy in a region, consider using a cross-region read replica instead of a global table.

**Does a global table work with any database engine?**

No, global tables are a feature of specific cloud database services. For example, Amazon DynamoDB Global Tables works only with DynamoDB. Other databases like MySQL or PostgreSQL offer cross-region replication but not full multi-master global table functionality.

## Summary

A global table is a database table that is automatically replicated across multiple geographic regions, allowing applications to serve users worldwide with low latency and high availability. The key characteristic is that any region can accept both reads and writes, and the changes are propagated asynchronously to all other regions. This provides eventual consistency globally but strong consistency within a region.

For IT certification exams, you need to understand the trade-offs: cost versus consistency, complexity versus simplicity. Global tables are a great answer when a scenario requires low-latency reads and writes from multiple regions and eventual consistency is acceptable. They are not the right choice when immediate global consistency is required. You should also be able to differentiate between different cloud providers’ implementations, especially AWS DynamoDB Global Tables (asynchronous, last-writer-wins) and Google Cloud Spanner (synchronous, strong consistency).

The takeaway for your exam is to listen carefully to the consistency requirement in the question. If the scenario says “globally consistent” or “strong consistency,” do not pick a traditional global table. If it says “low latency reads and writes from multiple regions” and “eventual consistency is fine,” then a global table is the perfect fit. Understanding this distinction will help you answer scenario-based questions correctly every time.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/global-table