La gestión de identidades y accesos (IAM) es un pilar fundamental en la arquitectura de cualquier sistema distribuido. Amazon Cognito ofrece una solución robusta para la autenticación y gestión de usuarios, pero su API nativa para la búsqueda de usuarios (ListUsers) presenta limitaciones significativas cuando se requieren capacidades avanzadas como búsquedas difusas, filtrado por atributos personalizados o consultas complejas con latencias de sub-segundo a escala. Este problema fundamental de la computación, la necesidad de indexación y búsqueda eficiente sobre grandes volúmenes de datos semi-estructurados, se ha abordado históricamente con sistemas de indexación invertida.
La solución propuesta aborda esta brecha al desacoplar la funcionalidad de búsqueda de la capa de gestión de identidades. Al construir una capa de búsqueda dedicada, se permite la optimización de la indexación y la consulta sin impactar el rendimiento o la disponibilidad del servicio de identidad principal. Esta estrategia es un patrón común en sistemas distribuidos donde las responsabilidades se segmentan para escalar de manera independiente y optimizar cada dominio.
Arquitectura del Sistema
La arquitectura se compone de dos flujos principales: Ingestión y Búsqueda. El flujo de Ingestión asegura la sincronización de los datos de usuario desde Amazon Cognito hacia un índice de búsqueda en Amazon OpenSearch Serverless, utilizando Amazon DynamoDB como una capa de persistencia intermedia y un mecanismo de Change Data Capture (CDC).
Los datos de usuario se ingieren a través de dos vías: los Cognito Lambda Triggers (Post-confirmation y Pre-token generation) capturan eventos de autenticación y actualización de perfil, escribiendo los datos relevantes en una tabla DynamoDB. Paralelamente, AWS CloudTrail y Amazon EventBridge capturan acciones administrativas de Cognito (ej. creación de usuarios vía consola o CLI) que no activan los triggers de Lambda, asegurando que todos los cambios de usuario sean registrados. DynamoDB Streams, el mecanismo de CDC de DynamoDB, emite eventos por cada cambio en la tabla de usuarios. Estos eventos son consumidos por una función Lambda (OSS ingest Lambda) que los procesa y actualiza el índice de OpenSearch Serverless. El flujo de Búsqueda expone una API RESTful a través de Amazon API Gateway, protegida por un Cognito Authorizer. Las solicitudes de búsqueda son manejadas por una función Lambda (Search Lambda) que consulta el índice de OpenSearch Serverless con una política de acceso de solo lectura, formatea los resultados y los devuelve al cliente. La elección de OpenSearch Serverless proporciona escalabilidad elástica y gestión simplificada del clúster de búsqueda, mientras que DynamoDB ofrece una base de datos NoSQL de baja latencia y alta disponibilidad para la persistencia de los datos de usuario antes de la indexación.
Flujo de Ingestión de Datos de Usuario (Cognito Triggers)
- 1 Cliente Inicia sign-up o login en Amazon Cognito.
- 2 Amazon Cognito Invoca Lambda Trigger (Post-confirmation o Pre-token generation).
- 3 Cognito Trigger Lambda Crea/actualiza registro de usuario en DynamoDB (email, nombre, grupos, timest...
- 4 DynamoDB Streams Detecta cambio en el registro de DynamoDB.
- 5 OSS Ingest Lambda Procesa evento de stream.
- 6 OpenSearch Serverless Indexa/actualiza datos de usuario.
Flujo de Búsqueda de Usuarios
- 1 Usuario Autenticado Envía consulta de búsqueda a la UI.
- 2 API Gateway Recibe solicitud, valida JWT con Cognito Authorizer.
- 3 Search Lambda Ejecuta la función Lambda con parámetros de búsqueda.
- 4 OpenSearch Serverless Lambda ejecuta la consulta contra el índice de OpenSearch.
- 5 Search Lambda Formatea y devuelve resultados paginados.
- 6 UI Muestra los resultados de la búsqueda.
| Capa | Tecnología | Justificación |
|---|---|---|
| orchestration | AWS Lambda | Funciones serverless para procesar eventos de Cognito, DynamoDB Streams y CloudTrail, así como para ejecutar la lógica de búsqueda. Permite un modelo de ejecución event-driven y escalabilidad automática. vs AWS Fargate (para contenedores), Amazon EC2 (para control total de infraestructura) Uso de Provisioned Concurrency para mitigar cold starts en triggers críticos; configuración de VPC para acceso a recursos privados. |
| storage | Amazon DynamoDB | Base de datos NoSQL de baja latencia para almacenar los perfiles de usuario. Actúa como fuente de verdad intermedia y habilitador de Change Data Capture (CDC) a través de DynamoDB Streams. vs Amazon Aurora (para SQL relacional), Amazon DocumentDB (para compatibilidad con MongoDB) Uso de DynamoDB Streams para emitir eventos de cambio de datos en tiempo real. |
| data-processing | Amazon OpenSearch Serverless | Motor de búsqueda e indexación para consultas complejas, búsquedas difusas y filtrado avanzado sobre los datos de usuario. La versión Serverless simplifica la gestión operativa y escala automáticamente. vs Amazon OpenSearch Service (para clústeres gestionados), Elasticsearch autogestionado en EC2 |
| security | Amazon Cognito | Servicio de gestión de identidades y accesos (IdP) para autenticación de usuarios y gestión de directorios. Sus Lambda Triggers son clave para la ingesta de datos. vs Auth0, Okta Configuración de Post-confirmation y Pre-token generation triggers para capturar eventos de usuario. |
| observability | AWS CloudTrail | Servicio de registro de actividad de API que captura acciones administrativas en Cognito. Es fundamental para la sincronización de cambios de usuario que no pasan por los triggers de Lambda. |
| messaging | Amazon EventBridge | Bus de eventos serverless que enruta eventos de CloudTrail a una función Lambda para procesar cambios administrativos en Cognito. vs Amazon SQS (para colas de mensajes), Amazon Kinesis (para streaming de datos) Reglas de eventos configuradas para filtrar eventos específicos de Cognito de CloudTrail. |
| networking | Amazon API Gateway | Punto de entrada para la API de búsqueda, proporcionando validación de solicitudes, autorización con Cognito Authorizer y gestión de tráfico. vs Application Load Balancer (ALB) con EC2/Fargate Uso de Cognito Authorizer para la validación de tokens JWT. |
Fundamentos Teóricos
El problema de la búsqueda eficiente sobre grandes colecciones de documentos textuales ha sido un área de investigación activa desde los inicios de la recuperación de información. El concepto de índice invertido, fundamental para sistemas como OpenSearch (y su predecesor Elasticsearch), fue formalizado en trabajos como 'Information Retrieval' de van Rijsbergen (1979) y es la base de la mayoría de los motores de búsqueda modernos. Permite una recuperación rápida de documentos que contienen términos específicos, a expensas de un mayor coste de almacenamiento y actualización.
La utilización de DynamoDB Streams como un mecanismo de Change Data Capture (CDC) para alimentar un índice secundario es una aplicación práctica del patrón de 'Event Sourcing' o 'Log-Based Data Integration', donde un log inmutable de cambios (el stream) se utiliza para propagar actualizaciones a sistemas downstream. Este patrón es ampliamente discutido en la literatura sobre sistemas distribuidos y bases de datos, y es clave para mantener la consistencia eventual entre diferentes almacenes de datos, como se describe en trabajos sobre sistemas transaccionales y replicación de bases de datos.