3. Arquitectura y Base de Datos

Sí, como datos BLOB (Binary Large Object), pero generalmente se recomienda almacenar los archivos en un sistema de archivos o almacenamiento en la nube (como AWS S3) y almacenar solo la ruta de referencia/URL en la base de datos.

SELECT * FROM table_name; (Recuperar datos), INSERT INTO table_name VALUES (...); (Agregar datos), UPDATE table_name SET column=value; (Modificar datos), DELETE FROM table_name WHERE condition; (Eliminar datos).

Una Function App está orientada a eventos: solo se ejecuta cuando es activada por disparadores específicos (solicitudes HTTP, temporizadores, mensajes de cola, etc.) y se apaga cuando no está en uso. Una Web App se mantiene encendida continuamente. Además, una Web App puede exponer una aplicación completa al usuario (front end y back end), mientras que un Web Service (o Function App) generalmente solo expone la lógica del back end. Una Web App también puede configurarse para exponer solo el back end, pero su diferencia clave es que permanece siempre activa.

Las bases de datos relacionales se caracterizan por las propiedades ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad), que garantizan el procesamiento confiable de transacciones. Las bases de datos no relacionales, por otro lado, se caracterizan por el teorema CAP (Consistencia, Disponibilidad, Tolerancia a Particiones), que establece que un sistema distribuido solo puede garantizar dos de estas tres propiedades simultáneamente.

ACID significa Atomicidad, Consistencia, Aislamiento y Durabilidad, y estas son las propiedades clave que las bases de datos relacionales garantizan para las transacciones. Para las bases de datos no relacionales o distribuidas, el concepto relevante es el teorema CAP. El teorema CAP establece que en un sistema de base de datos distribuida no se pueden garantizar simultáneamente las tres propiedades siguientes: Consistencia (C) – toda lectura recibe la escritura más reciente, Disponibilidad (A) – toda solicitud recibe una respuesta, y Tolerancia a Particiones (P) – el sistema continúa operando a pesar de particiones en la red. Un sistema distribuido debe elegir priorizar dos de estas tres garantías a expensas de la tercera.

Aplica principios de clean architecture, específicamente arquitectura hexagonal con ports y adapters. El objetivo es mantener la capa de dominio desacoplada tanto del framework como de la infraestructura. Para proveedores externos como sistemas de pago, define ports (interfaces) en la capa de dominio e implementa adapters en la capa de infraestructura. Para la comunicación entre servicios, usa patrones event-driven: publicar eventos y suscribirse a ellos. Este enfoque asegura que la lógica de negocio central permanezca independiente de las preocupaciones externas, facilitando el cambio de proveedores o de infraestructura sin afectar el dominio.

El enfoque recomendado es implementar el patrón Strategy para los canales de notificación. Cada canal (SMS, Email, Push) se implementa como una clase de estrategia separada. Para el take-home challenge, el envío real se puede simular con un log que indique que la notificación fue enviada por el canal especificado junto con los datos relevantes. El objetivo clave es hacer el código extensible para que se puedan agregar nuevos canales en el futuro sin modificar las implementaciones de los canales actuales, siguiendo el Principio Abierto/Cerrado.

Node.js maneja la concurrencia de forma inherente con el event loop. Para alto tráfico, primero configuraría un load balancer para escalar horizontalmente y manejar gran carga de usuarios. Luego implementaría rate limiting para no permitir que una misma IP consulte demasiado. Usaría caching con Redis para guardar en memoria las respuestas de la API. Para el procesamiento de pagos, evaluaría si debemos crear la comunicación con el banco o usar un microservicio que cumpla con las normas PCI tokenizando las tarjetas. Si el mercado llega a Europa, cumplir con la regulación SCA (Strong Customer Authentication), y si el banco solicita 3D Secure, mostrarle al usuario ese prompt. Usar MongoDB para guardar la referencia de las transacciones y analizar si conviene guardar datos del customer para suscripciones o cargos automáticos a tarjeta. Implementar validación de token para seguridad. Seguir el patrón Repository para desacoplar la lógica de negocio de la conexión a la base de datos o consumo de APIs externas. Adoptar una arquitectura event-driven para reaccionar a eventos como validar si el usuario existe en la vida real. Utilizar idempotencia para evitar pagos duplicados o crear usuarios repetidos. Empezar con un monolito y solo considerar la creación de un microservicio para servicios que no sean del core, para no romper el principio YAGNI.

Una estrategia clave es implementar cache para datos que no cambian con frecuencia. Al almacenar en cache datos relativamente estáticos, se reducen consultas o cálculos repetidos innecesarios, lo que puede mejorar significativamente los tiempos de respuesta. Otras estrategias comunes incluyen optimizar consultas a la base de datos, usar índices, implementar carga diferida (lazy loading), aplicar paginación, usar CDNs para recursos estáticos y hacer profiling de la aplicación para identificar cuellos de botella.

Una opción es utilizar WebSockets para mantener una conexión persistente y sincrónica entre los clientes, ordenando los mensajes por fecha y hora de publicación. Alternativamente, se puede emplear una cola de mensajes como Apache Kafka para garantizar la entrega ordenada y confiable de mensajes, manteniendo el sincronismo entre productores y consumidores. Ambos enfoques cubren el requisito central de mantener los mensajes consistentes y en orden entre los participantes.

Las consideraciones clave para este diseño incluyen: (1) Gestión de compras mediante cola — las solicitudes entrantes se encolan para establecer un orden justo y garantizar que solo una solicitud procese un asiento a la vez, evitando la sobrecompra. (2) Load balancing — distribuir el alto volumen de peticiones simultáneas entre múltiples instancias de servidor para evitar un punto único de falla y reducir la latencia. (3) Escalabilidad — arquitecturar el sistema para escalar horizontalmente (agregando más instancias) y manejar los picos repentinos de tráfico que ocurren al inicio de la venta. Los controles de concurrencia como el bloqueo optimista o pesimista sobre los registros del inventario de boletos también son críticos para garantizar la consistencia.

Al diseñar un sistema para insertar en masa 1 millón de registros desde un CSV en una base de datos SQL, considera el siguiente enfoque: 1. **Evitar ORM**: A esta escala, las capas ORM introducen sobrecarga innecesaria. Utiliza acceso directo a la base de datos. 2. **Lectura por chunks / buffer**: Parsea el CSV en fragmentos en lugar de cargar todo el archivo en memoria de una sola vez. 3. **Lectura binaria del archivo**: Prefiere I/O binario sobre librerías de texto plano para mejorar el rendimiento de lectura. 4. **Bulk insert nativo**: Aprovecha la funcionalidad de inserción masiva del motor de base de datos (p.ej., bulk insert de Oracle). Este enfoque puede cargar 1 millón de registros en aproximadamente 50 segundos. 5. **Validación de datos**: Antes de insertar, valida cada fila — tipos de datos, campos requeridos y restricciones de valor — para evitar que lleguen datos mal formados a la base de datos y reducir los rollbacks. 6. **Procesamiento asíncrono**: Dado que una carga de este tamaño no puede manejarse en una sola petición HTTP síncrona, procesa el archivo de forma asíncrona y devuelve de inmediato una respuesta al cliente indicando que la importación está en curso. 7. **Gestión de transacciones**: Envuelve las inserciones en transacciones y recopila las filas que fallen (p.ej., por violaciones de restricciones) para devolverlas al cliente como reporte de errores en lugar de abortar toda la operación. 8. **División en lotes**: En lugar de una sola petición enorme, divide la carga en lotes más pequeños (p.ej., 100 peticiones de 10,000 registros cada una) para mejorar la resiliencia y la capacidad de gestión.

El teorema CAP establece que un sistema de base de datos distribuida no puede garantizar simultáneamente las tres propiedades siguientes: Consistencia (C) — toda lectura recibe la escritura más reciente o un error; Disponibilidad (A) — toda solicitud recibe una respuesta sin error, aunque no necesariamente con el dato más reciente; y Tolerancia a Particiones (P) — el sistema continúa funcionando aunque ocurran particiones de red entre nodos. Como máximo se pueden garantizar dos de estas tres propiedades al mismo tiempo. Esto contrasta con las bases de datos relacionales, que se rigen por las propiedades ACID: Atomicidad, Consistencia, Aislamiento y Durabilidad. ACID se enfoca en la integridad de las transacciones dentro de una sola base de datos, mientras que CAP aborda las concesiones en sistemas distribuidos.

Se pueden considerar dos enfoques principales. Primero, usar WebSockets para mantener una conexión persistente y sincrónica entre los participantes y ordenar los mensajes por su marca de tiempo de publicación. Segundo, usar un sistema de colas de mensajes como Apache Kafka para mantener el orden de los mensajes y garantizar el sincronismo entre consumidores. La elección óptima depende de la escala y los requisitos específicos del sistema.

Para bases de datos NoSQL en general, es fundamental estudiar el Teorema CAP junto con las preguntas típicas asociadas a ese tipo de base de datos. Para MongoDB en particular, conviene centrarse en: operaciones CRUD (MongoDB Academy ofrece un curso breve), el aggregation framework, vistas, estrategias de mantenimiento de documentos, técnicas de indexación correcta y optimización del plan de consultas (el enfoque es análogo al de las bases de datos relacionales). El sharding es otro tema importante que aparece frecuentemente como pregunta de entrevista. Para SQL y bases de datos relacionales, los principios ACID son el concepto fundamental equivalente que se debe dominar.

Las pruebas técnicas de arquitectura para roles de Data Engineering suelen dividirse en dos tipos. El primero es de tipo conceptual, donde se espera que expliques cómo abordarías el proceso de datos y qué herramientas o tecnologías utilizarías para construir la solución. El segundo es de tipo práctico, donde se requiere producir trabajo concreto, como escribir código, diseñar pipelines de datos, manejar configuraciones, implementar jobs en Spark, construir validadores de calidad de datos, aplicar técnicas de normalización, entre otras tareas. Los entregables específicos dependen de las herramientas y el stack que utilice la empresa. Se recomienda estudiar tanto el lado conceptual (patrones de arquitectura, justificación en la elección de herramientas) como el lado práctico (programación en frameworks como Spark, controles de calidad de datos, diseño de pipelines).

Las bases de datos relacionales se caracterizan por las propiedades ACID: Atomicidad (una transacción se trata como una unidad — se completa totalmente o no se ejecuta en absoluto), Consistencia (una transacción lleva la base de datos de un estado válido a otro estado válido), Aislamiento (las transacciones concurrentes se ejecutan como si fueran secuenciales, evitando interferencias) y Durabilidad (una vez confirmada una transacción, persiste incluso ante fallos del sistema). Las bases de datos no relacionales (NoSQL) se describen mediante el teorema CAP, que establece que un sistema distribuido solo puede garantizar dos de las siguientes tres propiedades de forma simultánea: Consistencia (cada lectura recibe la escritura más reciente o un error), Disponibilidad (cada solicitud recibe una respuesta, aunque no necesariamente con los datos más recientes) y Tolerancia a particiones (el sistema sigue funcionando aunque se pierdan o retrasen mensajes entre nodos).

El teorema CAP establece que una base de datos distribuida no puede garantizar simultáneamente las tres siguientes propiedades: Consistencia (C) — cada lectura recibe la escritura más reciente o un error; Disponibilidad (A) — cada solicitud recibe una respuesta, aunque no necesariamente con el dato más reciente; y Tolerancia a Particiones (P) — el sistema sigue funcionando a pesar de fallos en la comunicación entre nodos. A diferencia de las bases de datos relacionales, que buscan cumplir las propiedades ACID, las bases de datos distribuidas y NoSQL están diseñadas en torno a las concesiones definidas por el teorema CAP, lo que significa que un sistema solo puede garantizar plenamente dos de las tres propiedades a la vez.

Los servicios principales de AWS pueden resumirse de la siguiente manera: - EC2: Alquilar servidores virtuales en minutos (instancias de cómputo gestionadas). - S3: Almacenamiento de objetos — guarda cualquier tipo de archivo en cualquier momento. - RDS: Servicio de base de datos relacional gestionado — sin necesidad de parchear servidores. - Lambda: Cómputo sin servidor — ejecuta código sin aprovisionar ni gestionar servidores. - API Gateway: Expone las APIs del backend de forma segura a consumidores externos. - CloudWatch: Monitoreo y observabilidad — rastrea métricas, logs y alertas para detectar fallos. - VPC: Virtual Private Cloud — tu red privada aislada dentro de AWS. - IAM: Gestión de identidades y accesos — define quién puede hacer qué en tus recursos de AWS. - CloudFront: Red de distribución de contenido — distribuye contenido globalmente con baja latencia. - DynamoDB: Base de datos NoSQL gestionada, diseñada para escalar horizontalmente sin sobrecarga operativa. - SQS: Simple Queue Service — mensajería confiable y desacoplada entre componentes de la aplicación. - SNS: Simple Notification Service — difunde alertas y notificaciones instantáneamente a múltiples suscriptores.