{
"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 los patrones de consulta, aproveché agresivamente los índices secundarios. Si bien la tabla principal utiliza la identificación única del documento como clave, un índice secundario organizado por identificación de miembro y categoría de documento permite consultas eficientes como «recuperar todos los documentos de una determinada categoría para un miembro determinado» sin costosos escaneos de la tabla.
El modelo de esquema en lectura de NoSQL resultó invaluable para la evolución. Cuando necesitábamos agregar un nuevo campo de metadatos opcional, no hubo una declaración ALTER TABLE riesgosa ni tiempo de inactividad. Los documentos nuevos simplemente comenzaron a incluir el atributo, mientras que los documentos existentes continuaron funcionando sin él. Esta agilidad nos permitió responder a nuevos requisitos en horas en lugar de semanas.
Incorporación de la recuperación ante desastres y la resiliencia de los datos
Una estrategia integral de recuperación ante desastres era esencial para la continuidad del negocio. Incorporé resiliencia tanto en la capa de metadatos como en la de contenido.
