Desarrollador backend Preguntas de entrevista & Respuestas

Respuesta modelo

Nuestra API empezó a devolver errores 500 de forma intermitente: afectaba aproximadamente al 5% de las solicitudes, pero solo en horas pico. Los logs mostraban timeouts de conexión a la base de datos, aunque la CPU y la memoria del servidor estaban bien. Añadí monitorización del pool de conexiones y descubrí que estábamos agotando el límite de 20 conexiones. La causa raíz: una nueva funcionalidad abría una transacción de base de datos, hacía una llamada HTTP a un servicio externo dentro de esa transacción, y ese servicio tardaba ocasionalmente más de 30 segundos en responder, manteniendo la conexión bloqueada. Lo resolví reestructurando el código para realizar la llamada HTTP fuera de la transacción y abrir la conexión solo para la escritura real. También aumenté el tamaño del pool a 50 como margen de seguridad y añadí alertas sobre el uso del pool. La tasa de errores 500 cayó a cero de inmediato.

Respuesta modelo

Diseñé una API de integración con socios que 15 empresas externas utilizarían para sincronizar datos de productos con nuestra plataforma. Antes de escribir una sola línea de código, realicé entrevistas con 5 potenciales consumidores de la API para entender sus patrones de integración. Aprendí que necesitaban operaciones en lote (no solo CRUD de registro único) y querían webhooks para actualizaciones en tiempo real. Diseñé la API con convenciones de nomenclatura coherentes, paginación, filtrado y mensajes de error detallados y accionables: no un simple '400 Bad Request', sino '400: El campo precio debe ser un número positivo. Recibido: -5.99.' Generé documentación OpenAPI directamente desde el código, creé un entorno sandbox con datos de prueba y escribí una guía de inicio rápido con ejemplos en Python, Node.js y curl. También versioé la API desde el primer día (v1 en la ruta de la URL). El resultado: el tiempo medio de integración fue de 3 días en lugar de las 2 semanas habituales del sector, y los tickets de soporte fueron un 70% menores que con la versión anterior de la API.

Respuesta modelo

Necesitábamos migrar 500 millones de filas de una base de datos MySQL monolítica a PostgreSQL manteniendo la aplicación en funcionamiento: el tiempo de inactividad cero era un requisito irrenunciable. Diseñé un enfoque por fases. Fase 1: configurar PostgreSQL con el nuevo esquema e implementar escritura dual; la aplicación escribe en ambas bases de datos simultáneamente. Fase 2: rellenar los datos históricos con un script de migración por lotes que procesaba 100.000 filas por hora durante las horas de menor actividad, con sumas de verificación para validar la integridad de los datos. Fase 3: trasladar el tráfico de lectura gradualmente a PostgreSQL mediante un indicador de funcionalidad (feature flag), empezando al 5% y aumentando durante 2 semanas mientras monitorizábamos discrepancias. Fase 4: una vez que el 100% de las lecturas estaban en PostgreSQL sin alertas de discrepancia, desactivamos las escrituras en MySQL y retiramos la base de datos antigua. La migración completa llevó 6 semanas. Durante la fase de lectura dual detectamos 3 errores de inconsistencia de datos que habrían causado problemas en producción con una migración big-bang.

Respuesta modelo

Realicé una auditoría de seguridad de nuestro sistema de autenticación y encontré varios problemas: los tokens JWT tenían una expiración de 30 días, los tokens de refresco se almacenaban en localStorage (vulnerables a XSS) y la limitación de velocidad solo se aplicaba a los endpoints de inicio de sesión. Implementé una mejora integral de seguridad: reduje la expiración de JWT a 15 minutos con refresco silencioso, moví los tokens de refresco a cookies HTTP-only seguras con SameSite=Strict, apliqué limitación de velocidad con ventana deslizante en todos los endpoints autenticados (100 solicitudes por minuto por usuario), añadí firma de solicitudes para operaciones sensibles (transferencias, cambios de contraseña) e implementé registro de auditoría para todos los eventos de autenticación. También configuré el análisis automatizado de vulnerabilidades en dependencias con Snyk dentro de nuestro pipeline de CI. Tras la implementación, superamos una prueba de penetración de terceros sin ningún hallazgo crítico ni de alta gravedad, frente a los 4 hallazgos críticos de la auditoría anterior.

Respuesta modelo

El teorema CAP establece que un almacén de datos distribuido puede garantizar como máximo dos de estas tres propiedades: Consistencia (cada lectura devuelve la escritura más reciente), Disponibilidad (cada solicitud recibe una respuesta) y Tolerancia a particiones (el sistema sigue operando a pesar de fallos de red entre nodos). Como las particiones de red son inevitables en sistemas distribuidos, la elección real es entre consistencia y disponibilidad durante una partición. Los sistemas CP (como PostgreSQL con replicación síncrona, MongoDB o HBase) prefieren no responder antes que devolver datos obsoletos: son adecuados para sistemas financieros donde los datos incorrectos son peores que la inactividad. Los sistemas AP (como Cassandra, DynamoDB o CouchDB) responden siempre, pero pueden devolver datos desactualizados: son adecuados para feeds de redes sociales, catálogos de productos o capas de caché donde la consistencia eventual es aceptable. En la práctica, elijo en función del coste del error: si los datos obsoletos provocan pérdidas económicas o problemas de seguridad, elijo CP. Si una brevísima desactualización es invisible para los usuarios, elijo AP por mayor disponibilidad y menor latencia.

Respuesta modelo

Evaluaría cuatro algoritmos según el caso de uso. Ventana fija: cuenta solicitudes en intervalos de tiempo fijos (por ejemplo, 100 por minuto). Es sencillo, pero permite ráfagas en los límites de ventana: un usuario podría hacer 100 solicitudes a las 0:59 y 100 más a la 1:00. Registro de ventana deslizante: registra la marca de tiempo de cada solicitud y cuenta las de la ventana anterior. Preciso, pero consume mucha memoria en APIs de alto volumen. Contador de ventana deslizante: híbrido entre los dos anteriores, usa el recuento de la ventana anterior ponderado por el solapamiento temporal. Buena precisión con bajo consumo de memoria. Cubo de tokens: los tokens se acumulan a una velocidad fija y cada solicitud cuesta un token. Permite ráfagas controladas manteniendo la velocidad media. Es mi opción predeterminada porque es intuitivo, gestiona bien el tráfico en ráfaga y es simple de implementar. Para la implementación: Redis con INCR y EXPIRE para la limitación distribuida, con el formato de clave user_id:endpoint:ventana. Devolvería cabeceras de límite de velocidad (X-RateLimit-Remaining, X-RateLimit-Reset) para que los clientes puedan autorregularse, y usaría respuestas HTTP 429 con una cabecera Retry-After.

Respuesta modelo

Un índice es una estructura de datos (típicamente B-tree o hash) que acelera la recuperación de datos a costa de escrituras más lentas y almacenamiento adicional. Es como el índice de un libro: en lugar de leer cada página para encontrar un tema, lo buscas en el índice y saltas directamente a la página correcta. Úsalos en: columnas en cláusulas WHERE (especialmente en tablas grandes), columnas de JOIN, columnas usadas en ORDER BY y columnas con alta cardinalidad (muchos valores únicos). No los uses en: tablas pequeñas (el escaneo secuencial es más rápido), columnas con baja cardinalidad (booleanos, campos de estado con 3 valores), columnas que se actualizan con frecuencia (el mantenimiento del índice penaliza el rendimiento) o tablas con mucha escritura donde el rendimiento de lectura no es crítico. Los índices compuestos importan: un índice en (user_id, created_at) ayuda a consultas que filtran por ambos campos, o solo por user_id, pero no por created_at solo. Uso EXPLAIN ANALYZE para verificar que las consultas realmente utilizan los índices que creo: el planificador de consultas a veces los ignora cuando estima que el escaneo secuencial es más rápido.

Respuesta modelo

Las transacciones ACID tradicionales no funcionan entre microservicios porque cada servicio gestiona su propia base de datos. La solución estándar es el patrón Saga: una secuencia de transacciones locales donde cada paso publica un evento que desencadena el siguiente, y cada paso tiene una transacción compensatoria para la reversión. Hay dos enfoques: coreografía (los servicios reaccionan a eventos de forma autónoma) y orquestación (un coordinador central gestiona el flujo). Prefiero la orquestación para flujos complejos porque la lógica está en un solo lugar y es más fácil de depurar. Ejemplo: procesar un pedido implica el servicio de Pedidos (crear pedido), el servicio de Pago (cobrar tarjeta) y el servicio de Inventario (reservar stock). Si el pago falla, el orquestador llama a la transacción compensatoria del servicio de Pedidos para cancelarlo. Si el inventario falla después de que el pago sea exitoso, el orquestador reembolsa el pago y cancela el pedido. Consideraciones clave: la idempotencia es crítica (cada paso debe manejar que se llame dos veces), las transacciones compensatorias deben ser fiables y se necesita observabilidad del estado de la saga para depurar flujos fallidos.

Respuesta modelo

Inmediato (primeros 15 minutos): habilitar caché agresiva en la CDN o en el proxy inverso para los endpoints con más lecturas. Activar el autoescalado de los servidores de aplicación si no está en marcha. Verificar si la base de datos es el cuello de botella: si es así, habilitar réplicas de lectura para las peticiones GET y añadir pooling de conexiones (PgBouncer para PostgreSQL). A corto plazo (siguiente hora): implementar throttling de solicitudes en endpoints no críticos para proteger los críticos. Añadir una cola para escrituras que puedan procesarse de forma asíncrona (eventos de analíticas de usuario, notificaciones por correo). Considerar un circuit breaker en las llamadas a servicios externos que podrían estar generando fallos en cascada. Si el tráfico era esperado (momento viral, lanzamiento de producto): escalar horizontalmente, añadir capas de caché y optimizar las consultas más frecuentes a la base de datos. Si es inesperado (posible DDoS): analizar los patrones de tráfico, habilitar limitación de velocidad por IP y considerar reglas de WAF. Tras el pico: hacer una revisión de planificación de capacidad para configurar disparadores de escalado que gestionen esto automáticamente la próxima vez.

Respuesta modelo

Nunca ejecutes ALTER TABLE directamente sobre una tabla con miles de millones de filas en producción: bloqueará la tabla durante horas. Usaría una herramienta de migración de esquema en línea como pt-online-schema-change (MySQL) o pg_repack (PostgreSQL), que crea una copia sombra de la tabla, aplica el cambio, sincroniza los datos mediante triggers y realiza el intercambio de tablas con un bloqueo mínimo. Para añadir una columna: añadirla primero como nullable (rápido, sin reescritura de tabla), rellenar los datos por lotes en horas de menor actividad (procesar 10.000 filas por lote con un retraso de 100 ms entre lotes) y añadir la restricción NOT NULL después de completar el relleno si es necesario. Para cambiar el tipo de una columna: crear una nueva columna con el tipo objetivo, hacer escritura dual en ambas columnas durante la migración, rellenar la nueva columna, cambiar las lecturas de la aplicación a la nueva columna y finalmente eliminar la antigua. Los principios clave: cada paso debe ser reversible, la migración debe ejecutarse en segundo plano sin bloqueos, y la aplicación debe funcionar correctamente en cada estado intermedio.

Respuesta modelo

Primero, implemento un patrón circuit breaker. Tras N fallos consecutivos (pongamos 5), abro el circuito: dejo de llamar a la API y devuelvo una respuesta de fallback (datos en caché, valores por defecto o un mensaje de degradación controlada) durante un período de enfriamiento. Tras el enfriamiento, permito que pase una única solicitud de prueba. Si tiene éxito, cierro el circuito y reanudo la operación normal. Segundo, añado lógica de reintento con retroceso exponencial para fallos transitorios: reintento tras 1 segundo, luego 2, luego 4, con jitter para evitar el efecto thundering herd. Tercero, implemento una cola de solicitudes para que las operaciones que dependen de esta API puedan reintentarse más tarde si fallan. Cuarto, alerto al equipo y consulto la página de estado del proveedor externo. Si el problema persiste, considero aumentar la caché de respuestas, construir un fallback a un proveedor alternativo o encolar solicitudes para procesamiento por lotes durante períodos estables. A largo plazo: para cualquier dependencia crítica de terceros, mantendría un acuerdo de nivel de servicio y una estrategia de fallback documentada antes de que se produzca el primer incidente.

Respuesta modelo

Lo diseñaría como un sistema basado en eventos con tres capas. Primera, la capa de solicitud de notificación: los servicios publican eventos de notificación en una cola de mensajes (RabbitMQ o SQS) con un payload independiente del canal: destinatario, tipo de notificación, nombre de plantilla y variables de la plantilla. Esto desacopla al emisor de los mecanismos de entrega. Segunda, la capa de orquestación: un servicio de notificaciones consume los eventos, consulta las preferencias del usuario (qué canales tiene habilitados), resuelve las plantillas y publica mensajes específicos por canal en colas separadas (cola de correo, cola de push, cola de SMS). Tercera, la capa de entrega: workers específicos por canal consumen de su cola y llaman al proveedor correspondiente (SendGrid para correo, FCM/APNS para push, Twilio para SMS). Cada worker gestiona reintentos, limitación de velocidad y lógica específica del proveedor de forma independiente. Decisiones de diseño clave: claves de idempotencia para evitar envíos duplicados, un registro de notificaciones para auditoría y depuración, almacenamiento de preferencias de usuario para gestionar bajas y selección de canal, y versionado de plantillas para poder actualizarlas sin redesplegar código. También implementaría una cola de mensajes muertos para las notificaciones con fallos permanentes, con alertas.