Marc Brooker, an engineer at AWS, reflects on the challenges of eventual consistency in database systems, particularly as they relate to read replicas. In his early days at AWS, the reliance on MySQL databases created operational headaches. While managed databases like Aurora MySQL have simplified operations, they still face issues with eventual consistency. This inconsistency can lead to baffling scenarios for application developers, such as receiving outdated or contradictory information when querying data. For example, a read operation might return a resource that has just been deleted, causing confusion and requiring developers to implement complex workarounds that can introduce more problems. Brooker points out that application builders encounter similar issues. When trying to scale by routing read traffic to replicas, they risk running into bugs due to stale data. This necessity forces them to direct certain reads to the primary database, negating the benefits of scalability that read replicas offer. The write-modify-read pattern, common in many applications, becomes problematic under eventual consistency. Reads from replicas could yield outdated results, complicating the writing process and potentially leading to unexpected behaviors in applications. Aurora DSQL addresses these challenges by ensuring all reads are strongly consistent. Its architecture employs a timestamp mechanism that guarantees replicas return data only after confirming they have received all relevant updates. This way, developers can avoid the complexities associated with eventual consistency. While Brooker acknowledges that eventual consistency has its place—especially in balancing latency and connectivity—he argues it shouldn't be a core feature of services or APIs that require reliability and high availability.