Everything you don’t need to know about Amazon Aurora DSQL: Part 5 – How the service uses clocks

Amazon Aurora DSQL employs an active-active database design, where all database resources are peers and serve both write and read traffic within a Region and across Regions. This distributed design facilitates synchronous data replication, providing automated zero data loss failover for single and multi-Region Aurora DSQL clusters.

In this five-part series on Aurora DSQL, I’ve covered the foundations, features and caveats, the behavior of transactions in Aurora DSQL, and the individual components. In this post, I explore how Amazon Aurora DSQL uses Amazon Time Sync Service to build a hybrid logical clock solution.

The ability of Aurora DSQL to operate in a scalable manner without extensive coordination within and across Regions is attributed to the utilization of Amazon Time Sync Service and the construction of a hybrid logical clock solution on top of it.

The significance of hybrid logical clocks in distributed systems

Physical clocks, although intuitive and aligned with our natural perception of time, encounter synchronization challenges in distributed systems. Conversely, logical clocks, such as the Lamport timestamp, excel in tracking causality but struggle to meet real-world timing requirements.

Hybrid logical clocks (HLCs) offer a sophisticated solution that harmonizes the advantages of both approaches. In Aurora DSQL, the HLC operates as follows:

1. The system maintains both physical and logical clock components
2. The clock value is updated prior to each read operation
3. If the physical clock operates at a faster pace (the typical scenario), logical time advances to synchronize
4. Conversely, if the physical clock lags, logical time progresses at approximately the physical clock rate

This hybrid approach ensures that time never retrogrades while maintaining a strong connection to physical reality. Other distributed databases, such as CockroachDB and MongoDB, have adopted hybrid clocks for their time management needs, demonstrating the relevance of this approach in Aurora DSQL. There are several benefits of HLCs, including:

• Consistency guarantees – When a client reads data from multiple database nodes, HLCs guarantee a consistent view of data. This facilitates Aurora DSQL to read from storage nodes in multiple Regions without the need for synchronization.
• Transaction management – Each transaction receives a start timestamp and a commit timestamp, facilitating reliable conflict detection based on these values.

Linearizability of read-only transactions

In practice, clock synchronization isn’t flawless. Modern systems employ sophisticated error bound tracking to manage this reality. Time measurements from the Amazon EC2 clockbound API include a current time estimate, an upper error bound, and a lower error bound. This delineates three time intervals: the known past (below the error bound), the unknown present (within the error bound), and the known future (above the error bound). By selecting the upper bound, the QP is assured that the data it requests from storage encompasses all committed transactions. This explains why read-only transactions are linearizable. It ensures that operations appear to execute in a consistent, real-time order without any parallelism within the system.

Understanding Transaction Timing in Amazon Aurora DSQL

Aurora DSQL provides strong consistency guarantees through its sophisticated handling of transaction timestamps. Let’s explore how the system manages transaction timing to ensure linearizability – meaning if Transaction B starts after Transaction A commits, B will always see A’s changes. We will explore this concept for read-write transactions only, as read-only transaction last for zero logical time as explained in the third post of this series and this concept isn’t required for that type of transaction.

When a transaction begins, the QP assigns it a start timestamp (τ-start) that’s guaranteed to be in the future. For any reads within the transaction, this timestamp is passed to storage, which ensures it has processed all prior transactions before executing the read operation.

During commit for a transaction:

1. The adjudicator assigns a commit timestamp (τ-commit).
2. The QP ensures this timestamp is verifiably in the past before confirming the commit to the user.

A Real-World Example

Let’s walk through two sequential transactions, A and B:

1. Transaction A starts:
   • Gets assigned start timestamp τ3
   • All actions within this transaction use this timestamp to ensure consistent views
   • Upon commit, receives timestamp τ5
   • System waits until τ5 is verifiably in the past before confirming commit
2. Transaction B starts (after A commits):
   • Gets assigned a start timestamp guaranteed to be higher than A’s commit timestamp
   • This ensures B will always see A’s changes

The system must carefully manage scenarios where clock uncertainties could create timing anomalies. For example, if Transaction A gets a wide timestamp window while Transaction B gets a narrower one, there’s a risk that B’s start timestamp could be lower than A’s, despite B starting after A commits.

To prevent such anomalies, Aurora DSQL implements additional a safeguard: The QP delays client responses until timestamp bounds of τ-start and τ-commit are verified to be in the past.

This robust approach to transaction timing helps Aurora DSQL deliver its strong consistency guarantees while maintaining high performance in distributed environments.

Using Amazon Time Sync Service for providing timing information

Time synchronization in distributed systems is a notoriously complex problem, especially when spanning multiple Regions. Aurora DSQL addresses this challenge by using Amazon Time Sync Service, which is accessible from all EC2 instances and uses atomic clocks synchronized with GPS satellites to achieve microsecond-level precision. This level of accuracy is critical for maintaining strong consistency across globally distributed nodes. Unlike traditional approaches relying solely on logical clocks or protocols such as Network Time Protocol (NTP), the Aurora DSQL hybrid model provides both causality and real-world alignment. This innovation not only improves transactional integrity but also minimizes latency during global writes, setting Aurora DSQL apart in the industry.

Possible use cases

The hybrid logical clock system opens new possibilities for Aurora DSQL in multiple industries. For example, financial institutions benefit from the guaranteed linearizability of transactions, ensuring accurate audit trails and compliance with regulations. Similarly, ecommerce platforms operating across multiple Regions can rely on Aurora DSQL for consistent inventory management and real-time order processing.

Conclusion

In this post, I explored the utilization of a hybrid clock model in Amazon Aurora DSQL, which draws upon the Amazon Time Sync Service to guarantee global strong consistency. For further insights into Aurora DSQL, I recommend consulting the Introduction and Dive Deep recordings from AWS re:Invent 2024 or reading Marc Brooker’s blog series on the subject matter.

About the author