# Aurora DSQL Multi-Região: Notas de Campo para Sistemas Financeiros

A expansão do Aurora DSQL para Stockholm, Espanha, Mumbai e Singapura em julho de 2026 coloca consistência forte multi-região ao alcance de arquiteturas financeiras na Europa e Ásia-Pacífico. Neste artigo, analiso os trade-offs reais de adotar active-active SQL distribuído, os padrões que funcionam e os anti-padrões que vão te custar caro em produção.

- URL: https://fernando.moretes.com/blog/aurora-dsql-multi-regiao-notas-de-campo-para-sistemas-financeiros-amazon-auror

- Markdown: https://fernando.moretes.com/blog/aurora-dsql-multi-regiao-notas-de-campo-para-sistemas-financeiros-amazon-auror/article.md?lang=pt

- Published: 2026-08-03T09:08:47.626Z

- Category: IA & Agentes

- Tags: aurora-dsql, multi-region, distributed-sql, financial-grade, active-active, consistency, serverless-db, aws-well-architected

- Reading time: 11 min

- Source: [Amazon Aurora DSQL adds multi-Region cluster support in four more Regions](https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-aurora-dsql-adds-multi-region-clusters-four-more-regions/)

---

Consistência forte multi-região sem gerenciar réplicas, failover manual ou lógica de conflito: isso é o que o Aurora DSQL promete. Com a expansão de 31 de julho de 2026 para Stockholm, Espanha, Mumbai e Singapura, o serviço agora cobre 16 regiões com clusters multi-região — o que muda o cálculo de adoção para quem projeta sistemas financeiros na Europa e Ásia-Pacífico. Mas 'serverless distributed SQL' esconde complexidade real. Estas são minhas notas de campo.

## O que mudou e por que importa agora

Antes desta expansão, clusters multi-região do Aurora DSQL estavam concentrados principalmente em regiões norte-americanas e em alguns pontos da Europa e Ásia. A adição de **Europe (Stockholm)** e **Europe (Spain)** fecha lacunas críticas de soberania de dados para clientes sujeitos ao GDPR com requisitos de residência em países nórdicos e ibéricos. A adição de **Asia Pacific (Mumbai)** e **Asia Pacific (Singapore)** é igualmente estratégica: são dois dos maiores hubs financeiros da Ásia, com regulações de localização de dados (RBI na Índia, MAS em Singapura) que exigem que dados de clientes permaneçam dentro de fronteiras geográficas específicas.

O que o Aurora DSQL oferece neste modelo é um **único banco de dados lógico com dois endpoints graváveis** — um em cada região pareada. Não há região primária e secundária no sentido tradicional. Ambas aceitam escritas, e o sistema garante consistência forte via protocolo de consenso distribuído. Se uma região ficar indisponível, a outra continua operando com o mesmo endpoint lógico. Para um sistema de pagamentos ou gestão de posições em tempo real, isso elimina a janela de indisponibilidade que normalmente existe durante um failover de banco de dados convencional — que, mesmo com Aurora Global Database, pode levar de 1 a 2 minutos.

A pergunta que faço imediatamente ao avaliar qualquer banco de dados distribuído não é 'funciona?' mas sim 'qual é o custo da consistência forte em latência de escrita?' No DSQL, escritas multi-região precisam de coordenação entre as duas regiões, o que introduz latência de rede inter-regional. Para pares como Mumbai-Singapura (~33ms RTT), isso é aceitável para transações financeiras que já toleram dezenas de milissegundos. Para pares transatlânticos, o cálculo muda.

## Aurora DSQL Active-Active: Topologia e Fluxo de Consistência

Dois endpoints graváveis, um banco lógico, consenso distribuído entre regiões. O cliente nunca vê duas bases — vê uma.

### 👤 Clients / Aplicações

- App EU (Stockholm/Spain) (frontend)
- App APAC (Mumbai/Singapore) (frontend)

### 🌍 Region A — Europe

- Writable Endpoint EU (Stockholm) (network)
- Aurora DSQL Shard Layer EU (data)
- Consensus Participant EU (compute)

### 🌏 Region B — APAC

- Writable Endpoint AP (Singapore) (network)
- Aurora DSQL Shard Layer AP (data)
- Consensus Participant AP (compute)

### 🔒 Security & Observability

- IAM Auth + KMS CMK (security)
- CloudWatch Database Insights (compute)

### Fluxos

- app-eu -> ep-eu: SQL/TLS
- app-ap -> ep-ap: SQL/TLS
- ep-eu -> dsql-eu: write
- ep-ap -> dsql-ap: write
- consensus-eu -> consensus-ap: consenso inter-região
- dsql-eu -> consensus-eu: coordena
- dsql-ap -> consensus-ap: coordena
- iam -> ep-eu: authn/authz
- iam -> ep-ap: authn/authz
- dsql-eu -> cw: métricas/logs
- dsql-ap -> cw: métricas/logs

## Consistência forte em sistemas distribuídos: o que o DSQL realmente garante

O Aurora DSQL anuncia **consistência forte multi-região** — uma afirmação que precisa ser destrinchada com cuidado antes de qualquer decisão arquitetural. Em bancos de dados distribuídos, 'consistência forte' pode significar coisas diferentes dependendo do modelo de isolamento de transações e do protocolo de replicação subjacente.

No contexto do DSQL, a consistência forte significa que uma leitura após uma escrita confirmada retornará o valor mais recente, independentemente de qual endpoint (EU ou APAC) a leitura seja feita. Isso contrasta diretamente com o modelo eventual do DynamoDB Global Tables, onde uma escrita em us-east-1 pode não ser imediatamente visível em ap-southeast-1. Para casos de uso financeiros — saldo de conta, posição de portfólio, limite de crédito disponível — essa garantia é não negociável.

O mecanismo por trás disso é um protocolo de consenso distribuído que coordena commits entre as regiões pareadas. O custo direto é **latência de commit proporcional ao RTT inter-regional**. Para Mumbai–Singapura (~33ms RTT), uma transação de escrita pode adicionar ~50–70ms ao tempo de resposta comparado a um banco single-region. Para Frankfurt–Irlanda (~20ms RTT), o overhead é menor. Isso significa que você precisa modelar seu SLO de latência de escrita incluindo essa coordenação — não assuma que DSQL multi-região terá a mesma latência que Aurora Serverless v2 single-region.

Um detalhe operacional importante: o DSQL usa autenticação IAM como mecanismo primário, sem suporte a usuários de banco de dados tradicionais baseados em senha como ponto de entrada principal. Isso é uma vantagem de segurança significativa em ambientes financeiros — elimina o problema de rotação de credenciais de banco de dados e permite políticas de acesso granulares via IAM conditions, incluindo `aws:SourceVpc` e `aws:RequestedRegion` para restringir qual workload pode escrever em qual endpoint.

> **Modelando latência de escrita multi-região:** Use a fórmula: P99_escrita_DSQL ≈ P99_escrita_single_region + (RTT_inter_regional × 1.5). O fator 1.5 cobre jitter de rede e overhead de protocolo de consenso. Para Mumbai–Singapura, isso significa planejar para ~80–100ms no P99 de escritas. Se seu SLO de transação exige <50ms end-to-end, revise a arquitetura: considere separar leituras (que podem ir ao endpoint local) de escritas críticas, ou avaliar se o caso de uso tolera esse overhead.

## Casos de uso financeiros onde o DSQL multi-região brilha — e onde não

Depois de avaliar o DSQL para diferentes padrões de workload financeiro, cheguei a uma taxonomia clara de onde ele agrega valor real versus onde introduz complexidade desnecessária.

**Onde o DSQL multi-região é a escolha certa:** Sistemas de gerenciamento de contas de clientes com presença geográfica distribuída — por exemplo, um banco digital que opera na Índia e em Singapura simultaneamente, onde um cliente pode iniciar uma transferência em Mumbai e verificar o saldo em Singapura milissegundos depois. O modelo active-active elimina a necessidade de lógica de roteamento de leitura no lado da aplicação. Outro caso forte é **gestão de limites de crédito em tempo real**: quando um cliente usa cartão em duas geografias quase simultaneamente, a consistência forte evita que o limite seja excedido por condições de corrida entre regiões — um problema real em sistemas com replicação eventual.

**Onde o DSQL multi-região não é a escolha certa:** Workloads de OLAP pesado ou relatórios históricos não se beneficiam da consistência forte e pagarão o overhead de latência sem necessidade. Para esses casos, Aurora Global Database com réplicas de leitura regionais ainda é mais adequado. Também não usaria DSQL multi-região para **event sourcing de alta frequência** — se você está gravando dezenas de milhares de eventos por segundo de uma única região, o overhead de consenso inter-regional é puro custo sem benefício. Nesse padrão, MSK (Kafka) como log de eventos com DSQL como store de estado projetado é uma arquitetura mais honesta.

Um ponto que frequentemente é ignorado: o modelo **serverless do DSQL significa que não há instâncias para dimensionar**. Você paga por DPU (Database Processing Units) consumidas. Isso é excelente para workloads com picos imprevisíveis — como processamento de fechamento de mercado — mas requer que você instrumente e monitore consumo de DPU ativamente para evitar surpresas na fatura. O CloudWatch Database Insights é o mecanismo correto aqui, e deve ser configurado desde o dia zero.

## Playbook: Adotando Aurora DSQL Multi-Região em Produção Financeira

1. **1. Mapeie o par de regiões correto para sua regulação** — Antes de criar o cluster, valide que ambas as regiões do par atendem aos requisitos de residência de dados da sua regulação (GDPR, RBI, MAS, LGPD). Para Brasil, note que São Paulo suporta apenas single-region cluster até o momento desta publicação — planeje para eventual expansão. Para Índia+Singapura, Mumbai+Singapore é o par natural e agora está disponível.

2. **2. Configure autenticação IAM com condições de contexto** — Crie roles IAM separadas por workload com condições `aws:SourceVpc` e `aws:RequestedRegion`. Nunca use credenciais de longa duração para conexão ao DSQL — use tokens de autenticação IAM de curta duração (15 minutos por padrão). Adicione `dsql:DbConnectAdmin` apenas para roles de migração/DDL, nunca para roles de aplicação.

3. **3. Habilite KMS CMK desde a criação do cluster** — Clusters DSQL suportam criptografia com chaves gerenciadas pelo cliente (CMK). Em ambientes financeiros, isso é obrigatório para conformidade. Use chaves multi-região do KMS para que o mesmo CMK lógico cubra ambas as regiões do cluster. Configure key rotation anual e CloudTrail para auditoria de uso da chave.

4. **4. Instrumente latência de commit por região desde o dia zero** — Configure CloudWatch Database Insights e crie alarmes em `CommitLatency` P99 por endpoint. Defina um SLO de latência de escrita explícito antes de ir para produção. Use OpenTelemetry no lado da aplicação para correlacionar latência de banco com latência end-to-end da transação — não confie apenas nas métricas do serviço gerenciado.

5. **5. Teste o cenário de falha de região de forma controlada** — Use AWS Fault Injection Service (FIS) para simular indisponibilidade de uma região. Valide que: (a) o endpoint da região sobrevivente continua aceitando escritas, (b) sua aplicação reconecta automaticamente sem intervenção manual, (c) o tempo de detecção + reconexão está dentro do seu RTO. Documente o comportamento observado em um ADR antes de promover para produção.

6. **6. Defina limites de DPU e alertas de custo antes do go-live** — O modelo serverless do DSQL pode gerar custos inesperados sob carga anômala. Configure AWS Budgets com alertas em 80% e 100% do orçamento mensal projetado. Use CloudWatch para criar métricas customizadas de DPU/hora e identifique padrões de consumo durante os primeiros 30 dias em produção.

## Segurança e conformidade: o que muda com DSQL multi-região

Em sistemas financeiros, a expansão para multi-região não é apenas uma decisão de disponibilidade — é uma decisão de conformidade. Cada nova região onde dados de clientes residem cria obrigações regulatórias adicionais. Com o DSQL, o modelo de dados é um **único banco lógico replicado entre regiões**, o que significa que dados escritos em Mumbai também existem em Singapura. Para clientes do setor bancário indiano sujeitos à regulação do RBI, isso requer validação explícita de que o par de regiões escolhido atende às diretrizes de localização de dados.

Do ponto de vista de IAM e Zero Trust, o DSQL tem uma postura de segurança mais forte do que Aurora tradicional por padrão. A autenticação baseada em IAM elimina o vetor de ataque de credenciais de banco de dados vazadas — um dos vetores mais comuns em breaches de dados financeiros. No entanto, isso cria uma nova superfície de ataque: **IAM role assumption**. Em ambientes financeiros, recomendo implementar `sts:ExternalId` para roles cross-account, `aws:PrincipalTag` conditions para segregação por ambiente (prod/staging), e CloudTrail com alertas em `dsql:Connect` de IPs ou roles inesperados.

Para criptografia, o uso de KMS CMK multi-região é o caminho correto. Uma chave multi-região do KMS é um conjunto de chaves relacionadas em múltiplas regiões que compartilham o mesmo material de chave e ID — isso permite que dados criptografados em Mumbai sejam descriptografados em Singapura usando a mesma chave lógica, sem necessidade de re-encriptação. Configure a key policy para restringir uso apenas às roles de serviço do DSQL e às roles de aplicação autorizadas, e habilite CloudTrail para todas as operações de `kms:Decrypt` e `kms:GenerateDataKey`.

Um aspecto de conformidade que frequentemente passa despercebido: **retenção e deleção de dados**. Em um banco de dados distribuído active-active, deletar um registro requer que a deleção se propague para ambas as regiões de forma consistente — o DSQL garante isso via seu protocolo de consenso. Mas você precisa validar que sua implementação de 'direito ao esquecimento' (GDPR Art. 17, LGPD Art. 18) funciona corretamente nesse modelo antes de ir para produção.

## Aurora DSQL Multi-Região vs. Alternativas para Sistemas Financeiros
| Critério | Critério | DSQL Multi-Região | Aurora Global DB | DynamoDB Global Tables | CockroachDB Dedicated |
| --- | --- | --- | --- | --- | --- |
| Consistência de escrita multi-região | Forte (consenso distribuído) | Eventual (réplica de leitura) | Eventual (LWW por padrão) | Serializável | — |
| Endpoints graváveis | 2 (active-active) | 1 primário + N leitura | N (todas as regiões) | N (todas as regiões) | — |
| Modelo de capacidade | Serverless (DPU) | Instância provisionada ou Serverless v2 | Serverless (WCU/RCU) | Instância provisionada | — |
| Compatibilidade SQL | PostgreSQL (subconjunto) | MySQL / PostgreSQL completo | API proprietária (PartiQL) | PostgreSQL completo | — |
| RTO em falha de região | Segundos (automático) | 1-2 minutos (failover manual/auto) | Segundos (automático) | Segundos (automático) | — |
| Gerenciamento operacional | Zero (totalmente gerenciado) | Baixo (instâncias gerenciadas) | Zero (totalmente gerenciado) | Médio (cluster gerenciado) | — |

## Anti-Padrões: O que Não Fazer com Aurora DSQL Multi-Região

- **Tratar DSQL como Aurora drop-in replacement:** O DSQL suporta um subconjunto de PostgreSQL. Recursos como stored procedures complexas, extensões (PostGIS, pg_partman), e alguns tipos de JOIN com subqueries correlacionadas podem não funcionar. Valide seu schema e queries em ambiente de staging antes de migrar qualquer workload de produção.
- **Ignorar a latência de consenso no design de SLOs:** Assumir que DSQL multi-região terá a mesma latência de escrita que um banco single-region é o erro mais comum. O overhead de consenso inter-regional é real e deve ser incorporado nos SLOs de transação desde o início do design.
- **Usar DSQL multi-região para workloads single-region:** Se seu workload opera em uma única região e não tem requisitos de DR ativo-ativo, o overhead de custo e latência do cluster multi-região não se justifica. Use single-region DSQL ou Aurora Serverless v2 para esses casos.
- **Não testar o comportamento de reconexão da aplicação:** O DSQL gerencia a continuidade do endpoint durante falha de região, mas sua aplicação precisa implementar retry com backoff exponencial e idempotência de transações. Não assuma que o driver PostgreSQL padrão vai lidar com isso automaticamente — teste explicitamente.
- **Misturar dados de diferentes regimes regulatórios no mesmo cluster:** Um cluster DSQL Mumbai–Singapura replica todos os dados entre as duas regiões. Se você tem dados de clientes indianos que não podem sair da Índia (per RBI guidelines), não os coloque no mesmo cluster que dados de clientes singaporenses. Use clusters separados por regime regulatório.
- **Negligenciar monitoramento de DPU em ambiente serverless:** O modelo de cobrança por DPU pode gerar surpresas significativas em workloads com padrões de acesso anômalos (ex: queries sem índice em tabelas grandes). Configure alertas de custo e analise o consumo de DPU semanalmente nos primeiros dois meses de produção.

## Observabilidade em sistemas DSQL multi-região: além das métricas padrão

Em sistemas financeiros, observabilidade não é opcional — é um requisito regulatório em muitas jurisdições. Para Aurora DSQL multi-região, a estratégia de observabilidade precisa cobrir três dimensões: **latência de consenso**, **divergência de estado entre regiões** (que no DSQL deve ser zero por design, mas precisa ser monitorada), e **correlação de transações end-to-end**.

O CloudWatch Database Insights é o ponto de partida correto. Ele fornece métricas como `CommitLatency`, `TransactionThroughput`, e `ConnectionCount` por endpoint. O que falta por padrão é a **correlação com traces de aplicação**. Aqui é onde OpenTelemetry entra: instrumente sua camada de acesso a dados com o SDK OTEL, propagando trace context através das conexões DSQL. Isso permite que você veja, em um único trace, o tempo gasto na aplicação, o tempo de transmissão para o endpoint DSQL, o tempo de execução da query, e o tempo de commit (que inclui o overhead de consenso inter-regional).

Um sinal de observabilidade que considero crítico e frequentemente negligenciado é o **monitoramento de transações abortadas por conflito**. Em um sistema active-active com consistência forte, conflitos de escrita concorrente entre regiões resultam em abort de transação — o protocolo de consenso detecta o conflito e aborta uma das transações. Em workloads financeiros normais, a taxa de conflito deve ser próxima de zero se o design de particionamento de dados estiver correto (ex: clientes indianos escrevem principalmente no endpoint Mumbai, clientes singaporenses no endpoint Singapore). Se você vir uma taxa de conflito elevada, isso é um sinal de que seu roteamento de escrita precisa ser revisado — não é um problema do DSQL, é um problema de design.

Para alertas operacionais, defino três níveis: (1) `CommitLatency P99 > 150ms` — investigação imediata, possível degradação de rede inter-regional; (2) `TransactionAbortRate > 0.1%` — revisão de padrão de acesso e roteamento; (3) `ConnectionCount approaching limit` — escalonamento de pool de conexões. Esses limiares devem ser calibrados com dados reais dos primeiros 30 dias em produção, não estimados a priori.

## Perguntas Frequentes: Aurora DSQL Multi-Região em Produção

### O DSQL suporta transações distribuídas que tocam dados em ambas as regiões simultaneamente?

Sim. O DSQL apresenta um único banco lógico — uma transação que começa no endpoint Mumbai pode ler e escrever dados que fisicamente residem em Singapura, e o sistema garante atomicidade e consistência via protocolo de consenso. O custo é latência adicional proporcional ao RTT inter-regional para o commit.

### Como funciona o failover quando uma região fica indisponível?

O DSQL mantém o endpoint da região sobrevivente ativo e aceitando escritas automaticamente. Não há failover manual necessário. Transações em voo no momento da falha podem ser abortadas e precisam de retry pela aplicação. O endpoint lógico do cluster não muda — sua string de conexão permanece a mesma.

### Posso usar DSQL com VPC privada ou apenas com endpoint público?

A documentação atual do DSQL indica suporte a conectividade via VPC endpoints (PrivateLink), o que é obrigatório em ambientes financeiros para eliminar tráfego de banco de dados pela internet pública. Valide a disponibilidade de VPC endpoints para DSQL na sua região específica antes de iniciar o design de rede.

### O que acontece com o RPO se ambas as regiões falharem simultaneamente?

Uma falha simultânea de ambas as regiões é um cenário de desastre catastrófico que vai além do modelo de disponibilidade do DSQL. Para esse cenário, você precisaria de uma estratégia de backup separada (ex: exports periódicos para S3 com replicação cross-region) e um plano de recuperação de desastre que inclua reconstrução do cluster a partir do backup. O DSQL protege contra falha de uma região, não contra falha simultânea de ambas.

### São Paulo (sa-east-1) suporta clusters multi-região?

Não, conforme o anúncio de 31 de julho de 2026. São Paulo suporta apenas clusters single-region. Para workloads brasileiros que precisam de active-active multi-região, será necessário aguardar expansão futura ou considerar arquiteturas alternativas com Aurora Global Database.

## Aurora DSQL Multi-Região pela Lente do AWS Well-Architected

- **security**: Autenticação IAM elimina credenciais de banco de dados estáticas. Use KMS CMK multi-região para criptografia, IAM conditions com aws:SourceVpc e aws:RequestedRegion, e CloudTrail para auditoria de todas as operações de conexão e acesso a chaves.
- **reliability**: Active-active com RTO de segundos elimina a janela de indisponibilidade de failover convencional. Implemente retry com backoff exponencial e idempotência de transações na camada de aplicação — o DSQL pode abortar transações em conflito e sua aplicação precisa estar preparada para isso.
- **performance**: Latência de escrita inclui overhead de consenso inter-regional. Otimize roteando escritas para o endpoint geograficamente próximo ao cliente. Leituras podem ser satisfeitas localmente. Monitore CommitLatency P99 e calibre SLOs com dados reais de produção.
- **sustainability**: O modelo serverless do DSQL elimina capacidade ociosa de instâncias provisionadas, reduzindo consumo de energia em períodos de baixa demanda. A consolidação de workloads em um único cluster lógico multi-região é mais eficiente do que manter múltiplos clusters independentes.

> **Nota do Arquiteto:** Na minha experiência com sistemas financeiros distribuídos, a maior armadilha ao adotar qualquer banco de dados active-active não é técnica — é organizacional: equipes assumem que 'active-active' significa 'sem failover para pensar', e negligenciam o design de idempotência de transações e os testes de caos. Com o DSQL, eu faria o seguinte antes de qualquer go-live financeiro: (1) um gameday completo simulando falha de região com FIS, com toda a equipe de engenharia presente; (2) um ADR documentando explicitamente o par de regiões escolhido, a justificativa regulatória, e os SLOs de latência de escrita com os números medidos em staging. A lição mais difícil que aprendi em sistemas distribuídos é que consistência forte no banco de dados não substitui idempotência na aplicação — o DSQL pode abortar sua transação, e se sua aplicação não sabe como re-tentar de forma segura, você tem um problema de corretude que nenhum banco de dados vai resolver por você.

## Veredicto: Quando Adotar Aurora DSQL Multi-Região

A expansão do Aurora DSQL para Stockholm, Espanha, Mumbai e Singapura é um marco real para arquiteturas financeiras na Europa e Ásia-Pacífico. O serviço entrega o que promete — consistência forte active-active com zero gerenciamento de instâncias — e a proposta de valor é genuína para workloads que precisam de RPO zero e RTO de segundos em múltiplas geografias. Minha recomendação: adote para sistemas de gestão de contas, limites de crédito em tempo real, e qualquer workload onde consistência eventual entre regiões cria risco de negócio mensurável. Não adote como substituto genérico de Aurora — valide compatibilidade de SQL, modele a latência de consenso nos seus SLOs, e implemente idempotência de transações antes do go-live. Para equipes brasileiras: aguardem a expansão multi-região para São Paulo antes de comprometer arquiteturas críticas com esse modelo — single-region DSQL em sa-east-1 já está disponível e é um bom ponto de partida para familiarização com o serviço.

## Referências

- [AWS What's New: Aurora DSQL multi-Region clusters in four more Regions (Jul 31, 2026)](https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-aurora-dsql-adds-multi-region-clusters-four-more-regions/)
- [Aurora DSQL Documentation — What is Aurora DSQL?](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/what-is-aurora-dsql.html)
- [Aurora DSQL Product Page](https://aws.amazon.com/rds/aurora/dsql/)
- [AWS What's New: Aurora DSQL available in five additional Regions (May 2026)](https://aws.amazon.com/about-aws/whats-new/2026/05/amazon-aurora-dsql-five-additional-aws-regions/)
- [Amazon CloudWatch Database Insights Documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights.html)
- [AWS Well-Architected Framework — Reliability Pillar](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)
- [Designing Data-Intensive Applications — Martin Kleppmann (Distributed Transactions chapter)](https://dataintensive.net/)
- [AWS Fault Injection Service — Chaos Engineering on AWS](https://aws.amazon.com/fis/)