# data[].attributes.body
Cada aluno deverá explicar para seus colegas de grupo o padrão sob sua responsabilidade.

Após as apresentações, o grupo deverá elaborar um quadro comparativo entre os padrões da categoria destacando:

o problema que ele resolve

requisitos de arquitetura (ex. atributos de qualidade) que esse padrão foca

os trade-offs do padrão

Discutir no grupo e fazer um resumo de possíveis situações onde cada padrão poderia ser útil.

# data[].attributes.headline
Lista de participantes com Num USP e nome

# data[].attributes.subject
Lista de participantes com Num USP e nome

# data[].attributes.body
Samuel Victorio Bernacci - 12703455

Daniel De Marco Fucci - 11218639

Gabriel Carvalho Fernandes - 13696662

...

# data[].attributes.body
Sistemas web modernos rapidamente esbarram em limites de um único banco de dados: gargalo de throughput, alta latência para usuários globalmente distribuídos, indisponibilidade quando o nó cai e equipes bloqueadas por um esquema centralizado. A arquitetura de dados distribuídos espalha informações por diversos nós/regiões para escalar capacidade, reduzir latência e eliminar pontos únicos de falha

# data[].attributes.body
Escalabilidade horizontal

Disponibilidade / tolerância a falhas

Performance / baixa latência

Manutenibilidade & autonomia de equipes

Agilidade (time‑to‑market)

# data[].attributes.body
Disponibilidade: Replicações assíncronas → risco de inconsistência temporal; custo operacional maior

Latência geográfica: Maior complexidade de replicação multi-mestre, conflitos de escrita, leis de dados locais

Custos de infraestrutura: Mais instâncias, tráfego de replicação, licenças; conta cresce rápido se a topologia não for otimizada

# data[].attributes.body
Em arquiteturas de microsserviços, o uso de um banco de dados compartilhado entre serviços gera forte acoplamento, dificultando a independência dos serviços e sua escalabilidade. O padrão Data-based per Service resolve isso ao garantir que cada serviço tenha seu próprio banco de dados, promovendo independência e autonomia.

# data[].attributes.body
Alta coesão e baixo acoplamento entre serviços

Escalabilidade independente dos serviços

Isolamento de falhas

Independência de deploy, versionamento e mudanças no modelo de dados

# data[].attributes.body
Vantagens x Desvantagens

Redução de acoplamento ❌ Aumenta a complexidade de consistência entre dados

Independência e facilidade de deploy ❌ Necessidade de orquestração para transações distribuídas

Melhor resiliência e tolerância a falhas ❌ Dificulta consultas cruzadas

Escalabilidade individual ❌ Possível duplicação de dados e lógica de sincronização

Aumento da segurança e controle de acesso ❌ Gerenciamento mais complexo de múltiplos repositórios

# data[].attributes.headline
Quando utilizar Distributed Data Architecture

# data[].attributes.subject
Quando utilizar Distributed Data Architecture

# data[].attributes.body
- Plataformas globais (SaaS, e‑commerce, redes sociais) que precisam de alta disponibilidade e baixa latência em vários continentes.

- Organizações orientadas por domínios onde múltiplas equipes querem evoluir dados de forma independente (Data Mesh).

- Workloads de leitura pesada que se beneficiam de réplicas adicionais.

-Negócios em que a preservação dos dados seja imprescindível

# data[].attributes.body
- E-commerces onde cada serviço tem carga e requisitos diferentes, o isolamento ajuda a evitar falhas em cascata e possui escalabilidade individual por serviço.

- Plataformas de ensino online, pois o progresso do aluno pode ser armazenado em um banco rápido e leve, notificações são temporárias e não exigem banco relacional.

# data[].attributes.body
O padrão Shared Data resolve o problema de compartilhamento eficiente e consistente de informações entre múltiplos componentes de um sistema. Em sistemas onde diversos módulos precisam acessar os mesmos dados (como em sistemas de gestão empresarial, sistemas bancários ou plataformas colaborativas), esse padrão provê um mecanismo centralizado de acesso e persistência de dados.

# data[].attributes.body
Consistência de dados – Ao centralizar o armazenamento, reduz-se o risco de inconsistências entre cópias dos dados.

Reutilização – Múltiplos componentes podem reutilizar os dados sem duplicação.

Integridade e disponibilidade – Facilita o controle de acesso centralizado aos dados.

# data[].attributes.body
- Sistemas de banco onde a performance e a consistência de dados e a integridade transacional são críticas.

- Sistemas ERP onde o modelo de dados é altamente relacional e interdependente, compartilhamento direto de dados evita inconsistências.

- Um sistema de e-commerce simples com poucos serviços e baixo volume de acesso, já que separar dados entre serviços criaria complexidade desnecessária e o custo de operação e manutenção de múltiplos bancos não se justifica.

# data[].attributes.body
Vantagens x Desvantagens

Centralização dos dados facilita consistência e integridade❌ Ponto único de falha: se o repositório falhar, o sistema pode parar

Reutilização dos dados por múltiplos componentes❌ Concorrência complexa: pode haver conflitos no acesso simultâneo

Controle de acesso centralizado aumenta a segurança❌ Escalabilidade limitada sem estratégias adicionais (como particionamento)

Mais fácil implementar políticas globais (como backup, auditoria)❌ Dificuldade de testes isolados dos componentes, devido à dependência do repositório