Projetando Armazenamento de Arquivos em Escala: System Design de Dropbox e Google Drive

Resumo: Um guia completo de system design para construir uma plataforma estilo Dropbox ou Google Drive com upload resumível, chunking, deduplicação, metadados, cursores de sincronização, compartilhamento, antivírus, cotas, retenção, tiering e durabilidade multi-região.

Um produto de armazenamento de arquivos parece simples até um notebook perder Wi-Fi em 97% do upload de um arquivo de 4 GB. Aí os problemas reais aparecem. O sistema precisa continuar do último byte aceito. Ele precisa evitar guardar o mesmo chunk um milhão de vezes.

Ele precisa sincronizar um rename feito no celular para três laptops sem baixar o arquivo inteiro. Ele precisa permitir que um usuário compartilhe uma pasta com um time enquanto outro revoga um link público. Ele precisa escanear malware, gerar previews, aplicar cotas, preservar versões e sobreviver a falhas de região. Este guia projeta esse sistema do zero.

O produto alvo é uma plataforma estilo Dropbox ou Google Drive, não apenas um object store bruto. Usuários pensam em arquivos, pastas, dispositivos, versões, links, permissões e sync offline. O backend pensa em linhas de metadados, chunks imutáveis, logs append-only, manifests, ACLs e jobs assíncronos. A arquitetura fica clara quando separamos esses dois mundos.

Sumário

• Análise de Requisitos
• Cálculos de Envelope
• Arquitetura de Alto Nível
• Design de APIs
• Modelagem de Dados
• Fluxo de Upload Resumível
• Chunking e Endereçamento por Conteúdo
• Estratégia de Deduplicação
• Download e Leituras por Range
• Sync Engine
• Cursor de Dispositivo e Change Log
• Watcher do Sistema de Arquivos Local
• Resolução de Conflitos
• Compartilhamento e ACLs
• Links Públicos
• Thumbnails e Previews
• Escaneamento de Malware
• Retenção, Versionamento e Lixeira
• Cotas e Fronteiras de Cobrança
• Tiering Hot e Cold
• Durabilidade Multi-Região
• Confiabilidade e Tratamento de Falhas
• Segurança e Privacidade
• Observabilidade e SLOs
• Dicas para Entrevistas
• Anti-Patterns
• Referências
• Referência Rápida

Análise de Requisitos

Comece definindo o produto. Não estamos projetando S3. Estamos projetando um workspace de arquivos para usuários. O sistema deve suportar web, mobile e desktop. Sync desktop faz parte do escopo porque ele gera boa parte das decisões difíceis.

Requisitos Funcionais

Funcionalidades principais:

1. Upload de arquivos por web, mobile e desktop.
2. Continuação de uploads interrompidos sem reiniciar do byte zero.
3. Download de arquivos completos e ranges de bytes.
4. Organização em pastas.
5. Rename, move, copy, delete e restore.
6. Preservação de versões.
7. Sincronização de pastas locais entre dispositivos.
8. Listagem de mudanças desde um cursor.
9. Compartilhamento com usuários, grupos e links públicos.
10. Aplicação de cotas.
11. Geração de thumbnails e previews.
12. Escaneamento de malware.
13. Retenção e janela de lixeira.
14. Suporte a arquivos grandes.
15. Suporte a pastas compartilhadas com alto fanout. Funcionalidades administrativas:
16. Auditoria de acessos e mudanças de permissão.
17. Legal hold e retenção empresarial.
18. Recuperação de conta e transferência de propriedade.
19. Detecção de abuso e padrões suspeitos de compartilhamento.
20. Residência regional de dados quando o produto exigir. Fora do escopo inicial:
21. Edição colaborativa de documentos.
22. Busca full-text em todos os tipos de arquivo.
23. Semântica de suíte office em tempo real.
24. Chaves de criptografia gerenciadas pelo usuário.
25. Sync peer-to-peer em LAN. Esses recursos podem ser adicionados depois. Eles não devem distorcer o design central.

Requisitos Não-Funcionais

Perguntas de Clarificação

Pergunte antes de desenhar caixas:

1. Sync desktop está no escopo?
2. Qual é o tamanho máximo de arquivo?
3. Pastas precisam ser fortemente consistentes?
4. Pastas compartilhadas são colaborativas ou somente leitura?
5. Links públicos funcionam sem login?
6. Deduplicação é global, por tenant ou desabilitada por privacidade?
7. Por quanto tempo guardamos deletados e versões antigas?
8. Existe requisito de residência de dados?
9. Servimos previews inline?
10. Upload em background no mobile é obrigatório?

Premissas Usadas Neste Design

Os números abaixo são premissas direcionais. Eles não são afirmações sobre uma empresa específica.

Usuários registrados: 500 milhões
Usuários ativos mensais: 120 milhões
Usuários ativos diários: 40 milhões
Usuários pagos / enterprise: 15 milhões
Dispositivos ativos médios por DAU: 2,2
Arquivos enviados por dia: 600 milhões
Bytes lógicos de upload por dia: 25 PB
Tamanho médio por contagem: 8 MB
Arquivos acima de 1 GB: 0,5% dos uploads
Chunk mediano: 8 MB
Economia por deduplicação: 25% dos bytes lógicos
Operações de metadados por DAU por dia: 120
Multiplicador de pico: 5x
Janela de lixeira: 30 dias
Retenção de versão: 30 dias grátis, 180+ dias pago

Modelo de Consistência

Use consistência forte para mutações de metadados visíveis. Se Alice renomeia report.pdf para board-report.pdf, a próxima listagem da pasta não deve mostrar os dois nomes como atuais. Use consistência eventual para artefatos derivados. Thumbnails, índices full-text, vereditos de malware, tiering e analytics podem atrasar. Use logs append-only para sync. Cada mutação de metadados escreve um evento durável. Dispositivos avançam cursores nesse log. Esse é o eixo de um sync confiável.

Cálculos de Envelope

Estimativas de envelope evitam arquitetura vaga. O objetivo não é precisão. O objetivo é revelar gargalos cedo.

Throughput de Upload

Bytes lógicos de upload/dia = 25 PB
Bytes/s médios = 25 PB / 86.400 ~= 289 GB/s
Multiplicador de pico = 5x
Ingress no pico ~= 1,45 TB/s
Após 25% de economia por dedup:
Bytes físicos novos/dia ~= 18,75 PB
Writes físicos médios ~= 217 GB/s
Writes físicos no pico ~= 1,08 TB/s

Ingress é grande, mas gerenciável quando uploads vão direto para gateways regionais e object storage. Ele não é gerenciável se servidores de aplicação proxyarem cada byte pelo serviço de metadados.

Throughput de Requisições

DAU = 40 milhões
Operações de metadados por DAU por dia = 120
Operações de metadados/dia = 4,8 bilhões
QPS médio de metadados = 55.555
QPS de pico ~= 277.777
Sessões de upload/dia = 600 milhões
Sessões de upload/s médias ~= 6.944
Sessões de upload/s no pico ~= 34.722
Writes de chunk/dia com chunk médio de 8 MB:
25 PB / 8 MB ~= 3,1 bilhões de tentativas/dia
QPS médio de chunk write ~= 36.000
QPS de pico de chunk write ~= 180.000

QPS de chunk write sozinho não basta. O tamanho do payload domina. O serviço de metadados deve ver apenas hashes, tamanhos, offsets e referências.

Storage de Metadados

Usuários ativos totais = 500 milhões
Arquivos médios por usuário ativo = 2.000
Registros lógicos de arquivo = 1 trilhão
Linha média de metadados = 700 bytes
Metadados brutos = 700 TB
Multiplicador de índices e histórico = 4x
Footprint de metadados ~= 2,8 PB
Change log:
Mudanças de metadados/dia = 4,8 bilhões
Evento médio = 700 bytes
Change log bruto/dia ~= 3,36 TB
Com replicação e índices ~= 15 TB/dia

Metadados viram um grande problema de banco distribuído. Mesmo assim, seguem muito menores que blob storage.

Blob Storage

Bytes lógicos/dia = 25 PB
Bytes físicos novos/dia após dedup = 18,75 PB
Overhead de retenção/versionamento = 1,35x
Overhead efetivo de replicação/erasure coding = 1,5x
Crescimento físico diário ~= 18,75 PB * 1,35 * 1,5
Crescimento backend diário ~= 38 PB/dia

Por isso lifecycle policy, compactação, cold tiering e fronteiras de dedup importam. Economias percentuais pequenas viram dinheiro grande.

Workload de Thumbnail e Preview

Arquivos enviados/dia = 600 milhões
Arquivos elegíveis a preview = 45%
Arquivos com artefatos derivados/dia = 270 milhões
Jobs médios por arquivo = 2,5
Jobs derivados/dia ~= 675 milhões
Jobs/s médios ~= 7.812
Jobs/s no pico ~= 39.000

Preview deve ser assíncrono. Não coloque isso no caminho crítico do commit.

Fanout de Sync

DAU = 40 milhões
Dispositivos ativos médios = 2,2
Dispositivos online = 88 milhões
Colaboradores médios por arquivo alterado = 1,8
Um write pode produzir:
- um evento do owner
- um evento da pasta pai
- várias visões compartilhadas
- várias notificações de device

Não empurre payload completo para cada device. Envie uma invalidação pequena. Devices puxam mudanças com cursor.

Arquitetura de Alto Nível

A arquitetura tem quatro planos:

1. Plano de metadados.
2. Plano de blob storage.
3. Plano de sync e notificações.
4. Plano de processamento assíncrono. Cada plano escala de forma diferente. Cada plano tem necessidades diferentes de consistência.

Control Plane vs Data Plane

Separe APIs de metadados de transferência massiva de bytes. APIs de metadados respondem:

• Quem é dono deste arquivo?
• Qual pasta contém o arquivo?
• Qual versão é atual?
• Quem pode acessar?
• Qual manifest representa os bytes? O data plane move bytes:
• upload de chunks;
• leitura por range;
• streaming de previews;
• replicação de blobs;
• compactação de objetos frios. Essa separação evita que metadados virem bombas caras de bytes.

Caminho Crítico de Upload

O caminho crítico deve ser curto:

1. Autorizar sessão de upload.
2. Reservar quota.
3. Aceitar chunks.
4. Verificar hashes.
5. Commitar manifest.
6. Criar versão de metadados.
7. Anexar evento no change log.
8. Retornar sucesso. Todo o resto roda depois. Scan de malware pode bloquear compartilhamento ou download dependendo da política, mas não deve exigir que o cliente mantenha o upload HTTP aberto.

Caminho Crítico de Sync

O caminho de sync:

1. Watcher local detecta mudança.
2. Cliente hasheia arquivo e envia chunks faltantes.
3. Cliente commita mutação com base revision.
4. Servidor valida conflitos e cria nova revision.
5. Servidor escreve change log.
6. Outros devices recebem invalidação.
7. Outros devices puxam mudanças por cursor.
8. Outros devices baixam chunks faltantes. Nenhum passo exige lock global. Consistência de pasta vem de version checks e transações de metadados.

Princípios Centrais

Guarde Conteúdo Como Chunks Imutáveis

Bytes de arquivo devem ser imutáveis após commit. Uma versão aponta para um manifest. Um manifest aponta para chunks. Chunks são endereçados por hash de conteúdo.

Guarde Namespace Como Metadados Mutáveis

O caminho /team/design/logo.png é metadado. Os bytes não são o caminho. Um rename deve atualizar metadados e emitir evento. Ele não deve copiar blobs.

Use Logs Append-Only Para Sync

Sync precisa de histórico. Um device não pergunta: "qual é o estado atual da pasta?" Ele pergunta: "o que mudou depois do cursor 928173?" Essa diferença importa. Estado atual serve para navegação. Histórico de mudanças serve para sincronização.

Torne Clientes Idempotentes

Clientes desktop fazem retry agressivo. Clientes mobile repetem depois de background wakeups. Browsers repetem depois de troca de rede. Todo endpoint de escrita deve aceitar idempotency keys ou operation IDs determinísticos.

Separe Intenção do Usuário de Enforcement Assíncrono

Usuário pode enviar arquivo rapidamente. O sistema pode depois:

• escanear;
• indexar;
• gerar previews;
• mover chunks frios;
• compactar versões deletadas. O estado visível deve expor pendências de segurança quando necessário. Não esconda policy assíncrona atrás de garantia síncrona falsa.

Design de APIs

Os exemplos usam REST por clareza. Internamente, o mesmo design funciona com gRPC.

Visão Geral dos Recursos

Criar Sessão de Upload

POST /v1/upload-sessions HTTP/1.1
Authorization: Bearer <token>
Idempotency-Key: 87fb7c9a-1b3c-4a9b
Content-Type: application/json

{"parent_id":"fld_9mS7","name":"resultado-trimestral.pdf","size_bytes":73400320,"content_type":"application/pdf","client_modified_at":"2026-02-11T10:21:30Z","mode":"add","base_revision_id":null,"chunking":{"strategy":"fixed","chunk_size_bytes":8388608,"hash":"sha256"}}

201 Created
Content-Type: application/json

{"upload_session_id":"ups_01HR8Q7TVX2M","expires_at":"2026-02-12T10:21:30Z","accepted_offset":0,"recommended_chunk_size_bytes":8388608,"max_parallel_chunks":4}

Notas de design:

• Idempotency-Key evita sessões duplicadas após retry.
• parent_id evita ambiguidade de path.
• base_revision_id permite detecção de conflito em overwrite.
• expires_at limita limpeza de sessões abandonadas.
• recommended_chunk_size_bytes deixa o serviço ajustar memória e throughput.

Enviar Chunk

PUT /v1/upload-sessions/ups_01HR8Q7TVX2M/chunks/0 HTTP/1.1
Authorization: Bearer <token>
Content-Type: application/octet-stream
Content-Length: 8388608
Content-Range: bytes 0-8388607/73400320
X-Chunk-SHA256: 6e7f...

202 Accepted
Content-Type: application/json

{"chunk_index":0,"start":0,"end":8388607,"accepted":true,"content_hash":"sha256:6e7f...","dedup_hit":true,"accepted_offset":8388608}

Para upload sequencial, use accepted_offset. Para chunks paralelos, acompanhe índices e monte o manifest no commit. Os dois modelos são válidos. Uploads sequenciais são mais simples. Chunks paralelos melhoram throughput em arquivos grandes.

Consultar Status do Upload

GET /v1/upload-sessions/ups_01HR8Q7TVX2M/status HTTP/1.1
Authorization: Bearer <token>

{"upload_session_id":"ups_01HR8Q7TVX2M","state":"open","accepted_ranges":[{"start":0,"end":33554431},{"start":50331648,"end":58720255}],"missing_ranges":[{"start":33554432,"end":50331647},{"start":58720256,"end":73400319}],"expires_at":"2026-02-12T10:21:30Z"}

Esse endpoint é essencial depois de restart do app mobile. Ele permite continuar sem confiar na memória local.

Commitar Upload

POST /v1/upload-sessions/ups_01HR8Q7TVX2M/commit HTTP/1.1
Authorization: Bearer <token>
Idempotency-Key: commit-87fb7c9a
Content-Type: application/json

{"parent_id":"fld_9mS7","name":"resultado-trimestral.pdf","mode":"add","client_operation_id":"op_desktop_0001982","chunks":[{"index":0,"offset":0,"size_bytes":8388608,"hash":"sha256:6e7f..."}],"file_hash":"sha256:b91a..."}

{"file_id":"fil_2bK9","revision_id":"rev_0042","path":"/financeiro/resultado-trimestral.pdf","size_bytes":73400320,"sync_cursor":"cur_99881271","scan_state":"pending","preview_state":"queued"}

Commit é a transação de metadados. Upload de chunk só prepara conteúdo. Commit torna o arquivo visível.

Baixar Arquivo

GET /v1/files/fil_2bK9/content HTTP/1.1
Authorization: Bearer <token>
Range: bytes=0-1048575

206 Partial Content
Content-Type: application/pdf
Content-Range: bytes 0-1048575/73400320
ETag: "rev_0042"
Cache-Control: private, max-age=3600

O download gateway resolve a revision para um manifest. Depois mapeia ranges do arquivo para reads de chunks.

Listar Filhos de Pasta

GET /v1/folders/fld_9mS7/children?page_size=200&page_token=abc HTTP/1.1
Authorization: Bearer <token>

{"entries":[{"id":"fil_2bK9","type":"file","name":"resultado-trimestral.pdf","revision_id":"rev_0042","size_bytes":73400320,"modified_at":"2026-02-11T10:24:12Z","scan_state":"clean"}],"next_page_token":"def","folder_revision":18821}

Listagem de pasta deve ser paginada. Pastas compartilhadas grandes podem conter milhões de entradas.

Listar Mudanças

GET /v1/changes?cursor=cur_99880000&limit=500 HTTP/1.1
Authorization: Bearer <token>
X-Device-Id: dev_macbook_123

{"changes":[{"change_id":"chg_99880001","type":"file_added","file_id":"fil_2bK9","parent_id":"fld_9mS7","revision_id":"rev_0042","name":"resultado-trimestral.pdf","content_hash":"sha256:b91a...","occurred_at":"2026-02-11T10:24:12Z"}],"next_cursor":"cur_99880500","has_more":true}

O cliente de sync só guarda next_cursor depois de aplicar o batch localmente. Isso dá entrega at-least-once com aplicação idempotente.

Criar Compartilhamento

POST /v1/shares HTTP/1.1
Authorization: Bearer <token>
Content-Type: application/json

{"resource_id":"fld_9mS7","resource_type":"folder","principal":{"type":"user","id":"usr_712"},"role":"editor","message":"Pasta de orçamento para revisão"}

{"share_id":"shr_18Y","resource_id":"fld_9mS7","effective_role":"editor","created_at":"2026-02-11T11:01:00Z"}

Criar Link Público

POST /v1/links HTTP/1.1
Authorization: Bearer <token>
Content-Type: application/json

{"resource_id":"fil_2bK9","role":"viewer","expires_at":"2026-03-01T00:00:00Z","password_required":true,"allow_download":true}

{"link_id":"lnk_9Ab","url":"https://files.example.com/s/lnk_9Ab","status":"active"}

Links públicos precisam de controles separados de shares autenticados. Eles são sensíveis a abuso. Eles devem ser revogáveis rapidamente.

Modelagem de Dados

O modelo separa namespace, conteúdo, permissões, sessões e sync.

Visão Entidade-Relacionamento

file_nodes

file_revisions

manifests

manifest_chunks

chunks

upload_sessions

change_events

Fluxo de Upload Resumível

Upload resumível não é opcional. A documentação do Google Drive descreve uploads resumíveis como úteis para arquivos grandes e redes instáveis. O Google Cloud Storage também expõe uploads resumíveis e discute chunk size com trade-off entre memória e velocidade. O protocolo tus formaliza ideia parecida com offsets e requests PATCH. Neste design, usamos o princípio sem copiar exatamente uma API externa.

Máquina de Estados do Upload

Modelo Sequencial por Offset

O design mais simples aceita bytes no offset atual. Se o cliente envia offset 64 MB enquanto o servidor só aceitou 56 MB, retorne conflito e o offset atual. Isso se aproxima do modelo de offset do tus.

Benefícios:

• correção mais simples;
• estado servidor mais simples;
• resume mobile mais fácil;
• menos buracos no estado. Custos:
• throughput menor em clientes com alta banda;
• não permite chunks fora de ordem.

Modelo de Chunks Paralelos

Para uploads grandes em desktop, permita chunks fora de ordem. Cada chunk tem índice, offset, tamanho e hash. O commit verifica que todos os ranges foram cobertos exatamente uma vez.

Upload paralelo exige validação mais forte:

1. Chunks devem cobrir [0, size) sem buracos.
2. Chunks não podem sobrepor.
3. Hashes devem bater com bytes staged.
4. Tamanho total deve igualar o declarado.
5. Commit deve ser idempotente.

Expiração e Limpeza

Sessões expiram. Chunks staged podem ser retidos por pouco tempo após expiração porque outra sessão pode deduplicar o mesmo conteúdo. Limpeza recomendada:

Regras de Resume

Algoritmo do cliente:

1. Ler checkpoint local.
2. Chamar status da sessão.
3. Comparar tamanho e modified timestamp local.
4. Recalcular hash de chunks ambíguos.
5. Enviar ranges faltantes.
6. Commitar com o mesmo operation id. Nunca confie só no estado local. O servidor é a fonte de verdade sobre bytes aceitos.

Chunking e Endereçamento por Conteúdo

Chunking afeta dedup, resume de upload e performance de download.

Chunking de Tamanho Fixo

Chunking fixo é simples. Exemplo: dividir cada arquivo em chunks de 8 MB.

bytes do arquivo:
[0..8MB) [8MB..16MB) [16MB..24MB) ...

Benefícios:

• offsets simples;
• range reads simples;
• upload paralelo simples;
• memória previsível;
• manifest simples. Custos:
• inserção no início desloca todos os chunks seguintes;
• dedup pior para arquivos editados e imagens de VM;
• tamanho fixo pode ser ruim para arquivos minúsculos.

Chunking Definido por Conteúdo

Chunking definido por conteúdo escolhe fronteiras via rolling hash. Ele é comum em backup e sistemas com forte dedup. Se bytes são inseridos no início, várias fronteiras posteriores continuam estáveis.

Benefícios:

• dedup melhor para conteúdo deslocado;
• sync eficiente de arquivos grandes editados;
• menos reupload após inserções. Custos:
• mais CPU;
• mapeamento de range mais complexo;
• chunks variáveis;
• compatibilidade cliente/servidor mais difícil.

Recomendação Prática

Use chunks fixos primeiro. Adicione chunking definido por conteúdo depois para sync desktop avançado. Divisão prática:

Hashes de Conteúdo

Use hashes criptográficos para endereçar chunks. SHA-256 é um default comum. Guarde hash do arquivo completo como metadado. Guarde hashes de chunks no manifest.

Finalidades do hash:

1. Detectar corrupção.
2. Suportar deduplicação.
3. Verificar uploads.
4. Tornar manifests determinísticos.
5. Criar cache keys. Limitação: Não exponha hashes brutos para usuários não confiáveis como prova de que outro usuário tem um arquivo. Isso vaza informação.

Estratégia de Deduplicação

Deduplicação economiza storage e banda. Ela também cria riscos de privacidade e abuso.

Níveis de Deduplicação

Padrão Seguro

Faça dedup server-side depois que os bytes chegam. Não permita que clientes consultem livremente se um hash existe globalmente. Fluxo:

1. Cliente envia chunk com hash.
2. Servidor verifica bytes contra hash.
3. Servidor consulta content index interno.
4. Se achar, referencia chunk existente.
5. Se não achar, grava novo chunk. O cliente só aprende que o próprio upload terminou. Ele não recebe um oracle global de existência.

Content Index

Reference Counting

Reference count ajuda, mas não basta. Falhas criam divergências:

• commit de manifest sucede, mas update de ref-count dá timeout;
• ref-count incrementa, mas transação de metadados aborta;
• retries duplicam incremento;
• deletes correm contra restores. Use ref-count como dica. Use reconciliação periódica como autoridade.

Garbage Collection

GC deve ser conservador. Processo recomendado:

1. Snapshot de manifests vivos.
2. Marcar chunks referenciados por manifests e versões retidas.
3. Incluir legal hold e janela de lixeira.
4. Varrer chunks antigos não marcados.
5. Deletar payloads depois de tombstone de metadados.
6. Reconciliar inventário de storage.

Download e Leituras por Range

Download é mais que GET object. O usuário pede um arquivo. A camada de storage tem chunks. O gateway mapeia ranges do arquivo para ranges de chunks.

Mapeamento de Range

Tamanho do arquivo: 20 MB
Tamanho do chunk: 8 MB
Chunk 0: bytes 0 - 8.388.607
Chunk 1: bytes 8.388.608 - 16.777.215
Chunk 2: bytes 16.777.216 - 20.971.519
Cliente pede:
Range: bytes=10.000.000-12.000.000
Gateway lê:
Chunk 1 offset 1.611.392 length 2.000.001

Caminho de Download

Cache

Cacheie manifests agressivamente. Cacheie metadados com TTL curto. Cacheie previews públicos em CDN. Não cacheie bytes privados em edge compartilhado sem tokens curtos e vinculados a acesso. Cache keys úteis:

Download de Arquivo Grande

Para arquivos grandes, suporte:

• HTTP range requests;
• download paralelo por range;
• resume após falha de rede;
• verificação de checksum;
• controle de banda;
• cache no device. Clientes desktop devem baixar chunks para arquivo temporário e renomear atomicamente após verificação.

Sync Engine

Sync é o coração do produto. Também é onde designs ingênuos quebram. O sistema precisa reconciliar três fluxos:

1. Mudanças locais no filesystem.
2. Eventos remotos do change log.
3. Ações do usuário em web/mobile.

Loop de Sync

Estado Local do Cliente

Clientes desktop precisam de banco local. Não infira tudo por timestamp do filesystem. Campos locais:

Invariantes de Sync

1. Nunca sobrescrever edição local não sincronizada silenciosamente.
2. Nunca marcar cursor como aplicado antes de aplicar localmente.
3. Nunca confiar só em mtime.
4. Nunca tratar path como identidade estável.
5. Tornar mutações idempotentes.
6. Lidar com eventos remotos duplicados.
7. Lidar com arquivos locais ausentes.

Estratégia de Notificação

Push notifications devem ser dicas. Elas não carregam a verdade completa. Fluxo:

1. Metadata service escreve evento.
2. Fanout envia invalidação para device.
3. Device chama /changes.
4. Device aplica batch.
5. Device grava novo cursor. Isso funciona mesmo com notificações perdidas. O cliente pode fazer polling periódico como fallback.

Cursor de Dispositivo e Change Log

O change log é o contrato de sync.

Particionamento do Change Log

Particione por namespace. Um namespace pode ser:

• conta pessoal;
• workspace de time;
• escopo de pasta compartilhada;
• drive enterprise.

Não exija um ID global monotônico. Isso cria coordenação desnecessária.

Semântica de Cursor

Um cursor significa: "O device observou e aplicou todas as mudanças até este ponto nesta visão de namespace." Cursor pode ser guardado no cliente, no servidor ou em ambos. Cursor server-side ajuda:

• diagnóstico multi-device;
• limpeza de devices obsoletos;
• push targeting;
• resume de sync após reinstalação. Cursor client-side ainda é necessário para offline.

Compactação

Change logs não podem crescer para sempre. Opções:

1. Manter eventos crus por 30-90 dias.
2. Materializar snapshots de pasta periodicamente.
3. Se cursor ficou velho, forçar full resync.
4. Manter tombstones tempo suficiente para devices offline. Caminho de full resync:
5. Cliente envia cursor antigo.
6. Servidor retorna cursor_expired.
7. Cliente busca snapshot do namespace.
8. Cliente reconcilia estado local.
9. Cliente grava novo cursor.

Tipos de Evento

Watcher do Sistema de Arquivos Local

Sync desktop depende de watchers da plataforma:

• FSEvents no macOS;
• ReadDirectoryChangesW no Windows;
• inotify/fanotify no Linux. Watchers não são perfeitos. Eles podem coalescer eventos. Eles podem descartar eventos. Eles podem perder mudanças durante sleep.

Pipeline do Watcher

Classificação de Evento

Mudanças Offline

Quando um laptop está offline:

1. Watcher registra mudanças locais.
2. DB local marca mutações pendentes.
3. Cliente envia conteúdo quando online.
4. Cliente submete mutações com base revisions.
5. Servidor detecta conflitos.
6. Cliente apresenta estado resolvido. Usuário deve conseguir trabalhar offline. O sistema não deve fingir que conflito não existe.

Resolução de Conflitos

Conflitos acontecem quando dois atores editam o mesmo arquivo lógico a partir da mesma base revision.

Checagem de Base Revision

Todo update inclui uma base revision.

{"file_id":"fil_2bK9","base_revision_id":"rev_0042","new_manifest_id":"man_778","client_operation_id":"op_laptop_555"}

Se a revision atual ainda é rev_0042, commit normal. Se a revision atual virou rev_0043, o servidor retorna conflito.

Árvore de Decisão

Política Prática

Para arquivos binários:

• criar cópia em conflito;
• incluir nome do device/usuário no filename;
• manter ambas revisions;
• notificar usuário. Para texto:
• merge three-way opcional;
• fallback para cópia em conflito. Para pastas:
• creates concorrentes com mesmo nome precisam de rename determinístico;
• deletes e moves concorrentes precisam de regra de tombstone.

Nome de Cópia em Conflito

Exemplo:

proposal.docx
proposal (copia em conflito de Anderson 2026-02-11).docx

UX de conflito importa. Sobrescrita silenciosa é inaceitável.

Compartilhamento e ACLs

Compartilhamento transforma storage pessoal em namespace colaborativo. Também complica cada read, write, sync e notificação.

Modelo de Permissão

Use ACLs com roles:

Avaliação de ACL

Herança

Pastas normalmente herdam permissões para descendentes. Evite copiar linhas de ACL para cada filho no share. Em vez disso:

• guarde ACL na raiz compartilhada;
• avalie ancestrais;
• cacheie permissões efetivas;
• invalide cache em mudanças de ACL. Pastas grandes tornam rewrites recursivos caros.

Cache de Permissão

Cache keys precisam de policy version.

key = principal_id + resource_id + acl_version
value = effective_role, expires_at

Quando ACL muda, incremente acl_version. Entradas antigas naturalmente dão miss.

Sync de Pasta Compartilhada

Uma mudança em pasta compartilhada deve aparecer para cada colaborador. Não duplique fisicamente metadados por usuário. Use mounts virtuais:

Links Públicos

Links públicos não são apenas ACL entries. Eles são capacidades bearer. Qualquer pessoa com URL pode acessar o recurso, salvo controles extras.

Campos de Policy de Link

Fluxo de Link Público

Revogação

Revogação deve ser rápida. Se CDN cacheia downloads públicos, vincule acesso a signed URLs de vida curta. Não deixe link revogado continuar funcionando por horas por causa de TTL da CDN.

Thumbnails e Previews

Preview generation é workflow assíncrono. Ele não deve bloquear commit de upload.

Pipeline de Preview

Isolamento de Workers

Preview workers parseiam arquivos não confiáveis. Rode-os em sandboxes com:

• sem acesso amplo à rede;
• limites de CPU e memória;
• timeouts;
• bibliotecas atualizadas;
• input read-only;
• service account separado;
• validação de output.

Tipos de Artefato

Consistência de Preview

O arquivo pode ficar visível antes do preview. Estados de UI:

• sem preview disponível;
• preview pendente;
• preview pronto;
• preview falhou;
• preview bloqueado por scan. Isso é melhor que atrasar o arquivo inteiro.

Escaneamento de Malware

Storage vira sistema de distribuição quando sharing existe. Malware scanning é obrigatório para links públicos e pastas compartilhadas.

Pipeline de Scan

Escolhas de Policy

Evitando Gargalo de Scan

Use filas com prioridade:

1. Arquivos com link público primeiro.
2. Arquivos recém-compartilhados depois.
3. Arquivos privados pessoais depois.
4. Histórico frio por último. Veredito de scan deve pertencer à revision, não apenas ao arquivo. Uma revision antiga limpa não diz nada sobre novo upload.

Retenção, Versionamento e Lixeira

Usuários esperam recuperação. Empresas esperam policy. Times de storage esperam custo limitado.

Modelo de Versionamento

Cada update cria uma revision imutável. O file node aponta para a revision atual. Revisions antigas seguem recuperáveis até expirar a retenção.

Semântica de Lixeira

Delete normalmente deve significar soft delete. Soft delete:

• marca file node como deletado;
• emite change event;
• oculta da listagem normal;
• mantém revisions e chunks durante janela de lixeira. Delete permanente:
• exige autorização mais forte;
• escreve tombstone;
• remove recuperabilidade quando policy permitir;
• deixa GC recuperar chunks.

Tabela de Retenção

Legal Hold

Legal hold sobrepõe delete do usuário. A UI pode esconder o arquivo. O backend deve preservar conteúdo até liberação. Isso significa que GC precisa consultar policy.

Cotas e Fronteiras de Cobrança

Quota é mais difícil com dedup. Storage físico e storage lógico visível são diferentes. Usuários devem ser cobrados por uso lógico. A plataforma otimiza uso físico internamente.

Fluxo de Reserva de Quota

Casos de Borda de Quota

Contadores de Quota

Use contadores fortemente consistentes no commit. Evite decrementar uso antes da retenção expirar. Mantenha:

• bytes lógicos ativos;
• bytes lógicos de versões;
• bytes de lixeira;
• bytes físicos únicos para custo interno;
• bytes reservados de upload.

Tiering Hot e Cold

A maioria dos arquivos esfria. O sistema deve manter chunks recentes e frequentes em storage hot, depois mover dados frios para storage mais barato.

Sinais de Tiering

Pipeline de Tiering

Comportamento de Restore

Reads do cold tier podem ser mais lentos. Produto user-facing precisa de policy:

• restore instantâneo para thumbnails e metadados;
• restore atrasado para arquivos grandes arquivados;
• planos pagos podem ter restore mais rápido;
• prefetch em background quando pasta é aberta. Não surpreenda usuários com restore de horas se o produto não comunica modo arquivado.

Durabilidade Multi-Região

O design precisa sobreviver a falhas de disco, máquina, rack, zona e região. A arquitetura Magic Pocket do Dropbox descreve publicamente blocos imutáveis, índice por hash, replicação entre zonas e erasure coding posterior para eficiência. Esse é o modelo mental correto.

Layout de Regiões

Política de Escrita

Para metadados:

• commitar em região primária ou grupo de consenso;
• replicar sincronicamente para outra região em namespaces enterprise críticos se necessário;
• anexar change log durável antes de confirmar mutação visível. Para chunks:
• escrever local primeiro;
• verificar checksum;
• replicar para outra zona/região rapidamente;
• marcar estado de durabilidade;
• bloquear visibilidade permanente se durabilidade mínima não foi atingida em planos críticos.

Estados de Durabilidade

Erasure Coding

Replicação é simples, mas cara. Erasure coding reduz overhead para chunks frios imutáveis. Trade-off:

• replicação dá reads rápidos e repair simples;
• erasure coding reduz custo de storage;
• encoding/repair consome compute e banda assíncrona. Use replicação para dados quentes recentes. Use erasure coding para dados frios estáveis.

Disaster Recovery

Objetivos de recuperação:

Confiabilidade e Tratamento de Falhas

Confiabilidade em file storage é nunca perder dado confirmado e nunca corromper namespace.

Matriz de Falhas

Idempotência Em Todo Lugar

Use operation IDs para:

• criar sessão de upload;
• enviar chunk;
• commitar upload;
• criar pasta;
• renomear arquivo;
• mover arquivo;
• deletar arquivo;
• compartilhar recurso;
• criar link público. Registro de idempotência deve guardar: | Campo | Propósito | |---|---| | idempotency_key | chave de retry | | actor_id | evita replay entre usuários | | request_hash | detecta reuso com payload diferente | | response_body | retorna mesmo resultado no retry | | expires_at | storage limitado |

Checksums

Verifique checksums em:

1. Hash de chunk no cliente.
2. Recebimento no upload gateway.
3. Write no object store.
4. Cópia de replicação.
5. Scrub assíncrono.
6. Download se o cliente pedir verificação.

Scrubbing

Scrub em background lê chunks e verifica hashes. Se aparecer corrupção:

1. marcar réplica como unhealthy;
2. ler réplica saudável;
3. reparar cópia corrompida;
4. emitir evento de durabilidade;
5. paginar só quando redundância cair abaixo do limiar.

Backpressure

Quando o sistema sobrecarrega:

• rejeite novas sessões antes de aceitar bytes que não consegue commitar;
• reduza chunks paralelos;
• desacelere previews;
• pause tiering frio;
• preserve commit de metadados;
• preserve download de arquivos existentes. Boa degradação protege dados do usuário primeiro.

Segurança e Privacidade

File storage é sensível por padrão. Usuários enviam impostos, contratos, fotos, código-fonte e documentos médicos.

Camadas de Segurança

Autenticação

Use:

• OAuth/OIDC para web e API;
• refresh tokens vinculados a device para desktop/mobile;
• access tokens curtos;
• step-up authentication para mudanças sensíveis de sharing;
• revogação de sessão.

Autorização

Todo read de conteúdo precisa de autorização. Não assuma que signed chunk URL basta se ele pode sobreviver a mudanças de permissão. Download tokens curtos devem incluir:

• file id;
• revision id;
• principal id ou link id;
• range ou escopo permitido;
• expiração;
• policy version.

Criptografia

Use:

• TLS em trânsito;
• envelope encryption em repouso;
• data keys por objeto ou chunk;
• KEKs gerenciadas por KMS;
• rotação de chaves;
• chaves separadas por tenant em planos enterprise quando necessário.

Privacidade e Dedup

Dedup global pode vazar informação se exposto como oracle. Evite APIs como:

Hash X já existe?

Aceite bytes e trate dedup como otimização interna.

Audit Logging

Audite:

• login;
• registro de device;
• read de arquivo em planos enterprise sensíveis;
• share criado;
• link criado;
• link revogado;
• permissão alterada;
• transferência de propriedade;
• delete permanente. Audit logs devem ser append-only. Eles devem ser consultáveis por admins enterprise dentro da policy.

Observabilidade e SLOs

Observabilidade deve mapear jornadas do usuário. Não monitore só CPU e tamanho de fila. Monitore se usuários conseguem fazer upload, download, navegação, sync, share e recovery.

SLOs Centrais

Métricas

Meça:

• QPS de criação de upload session;
• bytes/sec de chunk append;
• falhas de hash verification;
• dedup hit ratio;
• latência de commit por tamanho de arquivo;
• p99 do metadata DB;
• lag do change log;
• lag de cursor por device;
• drop rate de notificações;
• idade da fila de scan;
• idade da fila de preview;
• vazamento de quota reservation;
• erro de read no object store;
• lag de replicação cross-region;
• contagem de reparos por scrub.

Logs

Use logs estruturados com:

• request id;
• hash do user id;
• hash do device id;
• namespace id;
• file id;
• revision id;
• operation id;
• upload session id;
• região;
• classe de erro. Nunca logue nomes crus de arquivos ou senhas de link público sem política explícita de sanitização.

Traces

Trace através de:

1. API gateway.
2. Auth.
3. Permission.
4. Metadata DB.
5. Append no change log.
6. Enqueue de notification.
7. Blob index.
8. Object store. Uploads são long-lived. Traceie ciclo de vida da sessão com eventos, não só um span HTTP.

Alertas

Dicas para Entrevistas

Comece Pela Fronteira do Produto

Diga claramente: "Estou projetando um sistema user-facing de armazenamento e sync de arquivos, não apenas um object store." Isso mostra que você entende metadados, sync e sharing.

Desenhe os Quatro Planos

Use:

1. Plano de metadados.
2. Plano de blobs.
3. Plano de sync.
4. Plano assíncrono. Isso facilita raciocínio.

Enfatize Upload Resumível

Mencione:

• upload session;
• ranges ou offsets aceitos;
• chunk hashes;
• etapa de commit;
• idempotency key;
• TTL de limpeza.

Separe Upload de Chunk da Visibilidade do Arquivo

Esse é sinal de senioridade. Upload de chunk prepara bytes. Commit cria revision e evento.

Discuta Dedup Com Cuidado

Não diga apenas "usa hash e dedup global". Explique risco de privacidade. Diga que dedup pode ser interno e escopado por tenant.

Explique Sync Por Cursores

A API central de sync é:

GET /changes?cursor=...

Notificações são dicas. Cursores são a verdade.

Fale de Conflitos

Mencione base revision checks. Mencione cópias em conflito. Mencione que overwrite silencioso é inaceitável.

Saiba os Trade-offs

Anti-Patterns

Proxyar Todos os Bytes Por Servidores de Metadados

Servidores de metadados não devem trafegar 25 PB/dia. Use upload/download gateways e object storage.

Usar Path Como Chave Primária

Paths mudam. Use IDs estáveis. Paths são views sobre metadados.

Fazer Thumbnail de Forma Síncrona

Preview generation é caro e perigoso. Rode assíncrono em sandboxes.

Tratar Notificação Como Verdade

Notificações caem. Use-as como dicas. Devices devem puxar mudanças por cursor.

Ignorar Idempotência

Retries são normais. Sem idempotência, usuários recebem arquivos duplicados e quota inconsistente.

Dedup Global Sem Análise de Privacidade

Existência de hash pode vazar informação. Escopo dedup ou esconda isso atrás de verificação server-side.

Deletar Chunks Imediatamente

Deletes precisam de lixeira, retenção de versão, legal hold e janelas seguras de GC. Delete físico imediato quebra recovery e corre contra referências.

Assumir Que Watchers São Perfeitos

Filesystem watchers perdem eventos. Clientes precisam de scans periódicos e estado local.

Usar Um Banco Para Tudo

Metadados, blob indexes, change logs, audit logs e analytics têm padrões diferentes. Use storage especializado quando fizer sentido.

Referências

• Google Drive API: Upload file data
• Google Cloud Storage: Resumable uploads
• Google Drive API: Push notifications for resource changes
• tus resumable upload protocol 1.0.x
• Dropbox Engineering: Inside the Magic Pocket
• Dropbox Engineering: Improving storage efficiency in Magic Pocket
• AWS Architecture Blog
• NIST: Zero Trust Architecture SP 800-207

Referência Rápida

Componentes Centrais

APIs Críticas

POST /v1/upload-sessions
PUT  /v1/upload-sessions/{id}/chunks/{index}
GET  /v1/upload-sessions/{id}/status
POST /v1/upload-sessions/{id}/commit
GET  /v1/files/{id}/content
GET  /v1/folders/{id}/children
GET  /v1/changes?cursor=...
POST /v1/shares
POST /v1/links

Defaults de Design

Fechamento Para Entrevista

A resposta correta mais simples:

1. Guarde bytes como chunks imutáveis.
2. Guarde nomes, pastas, versões e ACLs como metadados.
3. Envie chunks por sessões resumíveis.
4. Commit um manifest para criar revision.
5. Emita toda mutação de metadados para um change log.
6. Sincronize devices por cursor.
7. Trate notificações como dicas.
8. Torne sharing, scanning, retenção, quota e tiering explícitos. Essa resposta cobre o sistema real. Ela evita o erro comum de projetar só um object store e chamar de Dropbox.