# DSQL Vignette: Wait! Isn't That Impossible?

DevFeed: [DSQL Vignette: Wait! Isn't That Impossible?](<https://devfeed.tech/articles/dsql-vignette-wait-isn-t-that-impossible-12566.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2024/12/06/inside-dsql-cap.html>)

Author: Marc Brooker

Published: 2024-12-06T00:00:00Z

Content type: article

Language: en

Sources: [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog.md>), [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog-2.md>)

Topics: [DSQL](<https://devfeed.tech/topics/dsql.md>), [Databases](<https://devfeed.tech/topics/databases.md>), [Availability](<https://devfeed.tech/topics/availability.md>), [Replication](<https://devfeed.tech/topics/replication.md>), [Latency](<https://devfeed.tech/topics/latency.md>), [Serverless](<https://devfeed.tech/topics/serverless.md>), [Network](<https://devfeed.tech/topics/network.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [availability](<https://devfeed.tech/tags/availability.md>), [database](<https://devfeed.tech/tags/database.md>), [dsql](<https://devfeed.tech/tags/dsql.md>), [latency](<https://devfeed.tech/tags/latency.md>), [network](<https://devfeed.tech/tags/network.md>), [replication](<https://devfeed.tech/tags/replication.md>), [serverless](<https://devfeed.tech/tags/serverless.md>)

## AI overview

This article examines how Aurora DSQL is designed for availability, durability, and strong consistency during infrastructure failures and network partitions. It focuses on the multi-region active-active architecture, including replicated regional infrastructure, a witness region, synchronous replication, latency trade-offs, and endpoint behavior when a region becomes unavailable.

## Source excerpt

DSQL Vignette: Wait! Isn't That Impossible? Laws of physics are real. In today's post, I'm going to look at how Aurora DSQL is designed for availability, and how we work within the constraints of the laws of physics. If you'd like to learn more about the product first, check out the official documentation, which is always a great place to go for the latest information on Aurora DSQL, and how to fit it into your architecture. In yesterday's post, I mentioned that Aurora DSQL is designed to remain available, durable, and strongly consistent even in the face of infrastructure failures and network partitions. In this post, we're going to dive a little deeper into DSQL's architecture, focussing on multi-region active-active. Aurora DSQL is designed both for single-region applications (looking for a fast, serverless, scalable, relational database), and multi-region active-active applications (looking for all those things, plus multi-region, synchronous replication, and the ability to support active-active applications). Aurora DSQL's Multi-Region Architecture Let's start by dipping into Aurora DSQL's multi-region architecture. We'll focus on multi-region clusters here, because they highlight the trade-offs best, but the same rules apply to single region clusters if we substitute AZ for region. In a multi-region DSQL cluster1 each of two regions runs a nearly complete copy of the cluster's infrastructure: a full copy of storage, enough Query Processors (QPs) to handle the load, and so on. The exception is the adjudicator: the leader adjudicator for each shard exists in only one region at a time. We'll come back to that, because it's a key part of the story. What benefits does this architecture offer? Symmetric latency for active-active multi-region architectures. The read, write, and commit latency you'll see will be very similar from both regions (this is unlike databases that do write forwarding, or have a primary region, where there'll be one "fast" region and one or mo