{
"unique_document_id": "aGVsbG93b3JsZA==",
"member_id": "123456",
"file_name": "employment_contract.pdf",
"document_category_id": 101,
"document_subcategory_id": 10110,
"document_extension": ".pdf",
"document_size_in_bytes": 245678,
"date_added": "2025-09-20T12:11:01Z",
"date_updated": "2025-09-21T15:22:00Z",
"created_by_user_id": "u-01",
"updated_by_user_id": "u-02",
"notes": "Signed by both parties"
}Para padrões de consulta, aproveitei os índices secundários de forma agressiva. Embora a tabela primária use o ID exclusivo do documento como chave, um índice secundário organizado por ID do membro e categoria do documento permite consultas eficientes como “recuperar todos os documentos de uma determinada categoria para um determinado membro” sem digitalizações caras da tabela.
O modelo esquema na leitura do NoSQL provou ser inestimável para a evolução. Quando precisamos adicionar um novo campo de metadados opcional, não houve nenhuma instrução ALTER TABLE arriscada ou tempo de inatividade. Novos documentos simplesmente começaram a incluir o atributo, enquanto os documentos existentes continuaram funcionando sem ele. Essa agilidade nos permitiu responder aos novos requisitos em horas, em vez de semanas.
Construindo recuperação de desastres e resiliência de dados
Uma estratégia abrangente de recuperação de desastres foi essencial para a continuidade dos negócios. Incorporei resiliência nas camadas de metadados e conteúdo.
