Preguntas de entrevista para Desarrollador Backend

Respuesta modelo

Diseñé el servicio de pedidos de una plataforma de comercio electrónico con picos de 4.500 peticiones por segundo en rebajas. Opté por un monolito modular en Spring Boot con fronteras claras por dominio, en lugar de microservicios desde el primer día, porque éramos cinco personas y el coste operativo de doce despliegues independientes no se justificaba. Modelé pedidos y pagos en PostgreSQL con particionado por rango mensual y publiqué los cambios de estado mediante patrón outbox transaccional hacia Kafka, de modo que la publicación del evento nunca pudiera divergir de la transacción de base de datos. Descarté el envío directo a la cola dentro de la transacción por el riesgo de escritura dual, y descarté event sourcing completo porque el equipo no tenía experiencia previa y la trazabilidad exigida se cubría con una tabla de auditoría. Un año después extrajimos facturación como servicio independiente, que era justamente lo que las fronteras del módulo permitían hacer sin reescribir.

Respuesta modelo

Primero separo mitigación de diagnóstico: si hay impacto en usuarios, activo la medida de contención disponible, ya sea escalar réplicas, desactivar una funcionalidad con un feature flag o revertir el último despliegue. Después miro los datos en este orden: latencia por endpoint y por percentil en Grafana, trazas distribuidas en OpenTelemetry para saber si el tiempo se va en la base de datos, en una llamada externa o en la propia aplicación, y a continuación métricas de saturación (CPU, uso del pool de conexiones, pausas de recolección de basura, lag de Kafka). En el último caso real, el p95 se disparó tras un despliegue y las trazas señalaban una consulta que había perdido el índice porque un cambio en el ORM añadió una función sobre la columna filtrada. Lo confirmé con EXPLAIN ANALYZE, revertí la consulta y añadí una prueba que falla si el plan de ejecución hace un recorrido secuencial sobre esa tabla.

Respuesta modelo

Empiezo midiendo, no comprando máquinas. Ejecuto una prueba de carga con k6 reproduciendo el reparto real de endpoints y busco el primer cuello de botella, que en mi experiencia casi nunca es la CPU de la aplicación sino la base de datos o el pool de conexiones. A partir de ahí actúo por capas: caché de lecturas en Redis con invalidación por evento para el catálogo, réplicas de lectura para las consultas analíticas, PgBouncer delante de PostgreSQL para no agotar las conexiones, y paso a asíncrono de todo lo que no necesite responder en la petición, como correos, facturación o indexado, enviándolo a Kafka. Añado limitación de peticiones por cliente y un mecanismo de degradación elegante: si el servicio de recomendaciones no responde en 200 ms, devuelvo el listado sin personalizar en lugar de dejar caer la página. Y fijo el autoescalado sobre una métrica que refleje la carga real, como peticiones en cola, no sobre la CPU.

Respuesta modelo

Publiqué una migración que añadía una columna con valor por defecto y un índice sobre una tabla de 300 millones de filas dentro de la misma transacción. En preproducción, con 200.000 filas, tardaba dos segundos; en producción bloqueó la tabla durante once minutos y el checkout dejó de funcionar. Corté por lo sano revirtiendo la migración y liberando el bloqueo, y lo repetimos esa misma noche creando el índice con CONCURRENTLY y separando el cambio en pasos de expand-contract. Lo que cambió después fue el proceso, no solo mi cuidado: incorporamos un entorno de preproducción con un volumen representativo, una revisión obligatoria de toda migración por una segunda persona y una regla explícita de no ejecutar DDL sobre tablas grandes sin plan de reversión. Escribí el post mortem y lo presenté en la sesión de equipo, sin buscar culpables.

Respuesta modelo

Decido por organización y por ritmo de cambio, no por escala teórica. Si hay un solo equipo, un monolito modular con fronteras internas bien definidas es más rápido de desarrollar y muchísimo más barato de operar: una sola base de datos, transacciones locales, un despliegue. Separo un servicio cuando aparece alguna de estas tres señales: dos equipos se bloquean mutuamente en el mismo despliegue, una parte tiene un perfil de escalado radicalmente distinto (por ejemplo, un procesador de imágenes intensivo frente a una API de lectura), o existe una exigencia de aislamiento por seguridad o cumplimiento normativo. Antes de separar exijo tres cosas: observabilidad distribuida, contratos de API versionados y una estrategia clara para la consistencia, normalmente eventos con outbox y sagas en lugar de transacciones distribuidas.

Respuesta modelo

Negocio el alcance, nunca la red de seguridad. Mantengo siempre las pruebas del camino crítico y las migraciones reversibles, porque son lo que evita una incidencia cara, y en cambio propongo recortar funcionalidad secundaria, dejar la optimización para una segunda iteración o publicar detrás de un feature flag para un porcentaje reducido de usuarios. En un cierre de trimestre con dos semanas de plazo lo planteé así a Producto: entregamos el flujo de pago con un solo método y el resto en la siguiente iteración, con pruebas de integración completas sobre Testcontainers. Salió en fecha, sin incidencias, y la deuda quedó registrada como tarea con fecha y responsable, no como un comentario TODO en el código.

Con READ COMMITTED, que es el nivel por defecto en PostgreSQL, cada sentencia ve una instantánea nueva, por lo que dos lecturas dentro de la misma transacción pueden devolver valores distintos si otra transacción confirma cambios entremedias. Con REPEATABLE READ, la instantánea se fija al inicio de la transacción y todas las lecturas son coherentes entre sí, a cambio de que una escritura conflictiva provoque un error de serialización que la aplicación debe reintentar. Uso READ COMMITTED para la operativa normal de una API, donde cada petición es corta y no necesita coherencia entre varias lecturas. Elijo REPEATABLE READ o incluso SERIALIZABLE para procesos de cierre contable, informes y cálculos que leen varias tablas relacionadas y no pueden tolerar una lectura no repetible. Cuando subo el nivel, siempre implemento reintento con retroceso exponencial, porque los errores de serialización dejan de ser una excepción rara y pasan a ser parte del flujo normal.

Exijo al cliente una cabecera Idempotency-Key con un identificador único por intento de pago. Al recibir la petición, inserto esa clave en una tabla con restricción de unicidad dentro de la misma transacción que registra el cobro. Si la inserción falla por clave duplicada, devuelvo la respuesta previamente almacenada para esa clave, con el mismo código de estado y el mismo cuerpo, en lugar de volver a cobrar. Guardo también un resumen del cuerpo de la petición para detectar el caso de una misma clave reutilizada con datos distintos, que devuelvo como error 422. Para la ventana en la que la operación está en curso registro el estado como en proceso y respondo 409 si llega una petición concurrente. Le doy a la clave una caducidad razonable, de veinticuatro horas, y la propago al proveedor de pagos para que la idempotencia sea de extremo a extremo, no solo en mi capa.

Resuelve el problema de la escritura dual: si guardo el pedido en PostgreSQL y publico el evento en Kafka como dos operaciones separadas, cualquier caída entre ambas deja el sistema inconsistente, con un pedido sin evento o con un evento sin pedido. Con el patrón outbox escribo el evento en una tabla de la misma base de datos dentro de la misma transacción que el cambio de negocio, de modo que ambos se confirman o ninguno lo hace. Un proceso independiente, normalmente un conector de captura de cambios como Debezium o un publicador con sondeo, lee esa tabla y publica en Kafka marcando lo enviado. La entrega resultante es at-least-once, así que los consumidores deben ser idempotentes, habitualmente descartando por identificador de evento ya procesado. El coste es una tabla adicional que hay que purgar y una latencia de publicación de unos pocos cientos de milisegundos, que en la práctica compensa frente a perder eventos de pago.

Aparece cuando recupero una lista de N entidades con una consulta y después el ORM lanza una consulta adicional por cada elemento para cargar una relación perezosa, de modo que una única petición acaba generando cientos de viajes a la base de datos. Lo detecto de tres maneras: activando el registro de sentencias SQL en desarrollo, observando en las trazas de OpenTelemetry un span de servicio con decenas de spans de base de datos hijos, o midiendo una latencia que crece linealmente con el tamaño de página. Lo corrijo con carga anticipada explícita, mediante JOIN FETCH o entity graphs en JPA, con select_related y prefetch_related en Django, o resolviendo por lotes con un dataloader en GraphQL. Para que no reaparezca, añado una prueba de integración que cuenta el número de sentencias ejecutadas en el endpoint y falla si supera un umbral fijado.

Creo un índice compuesto cuando las consultas filtran de forma habitual por varias columnas a la vez. El orden importa porque el índice solo puede aprovecharse por prefijo: coloco primero las columnas con igualdad, después la de rango y por último las que solo se usan para ordenar. Para una consulta que filtra por estado igual a pendiente y fecha de creación mayor que un valor, ordenando por fecha, el índice adecuado es sobre estado y fecha en ese orden. Si el estado pendiente representa el 2 % de la tabla, prefiero un índice parcial con la condición del estado en el WHERE, que ocupa una fracción del espacio y se mantiene mucho más barato en escritura. Verifico siempre con EXPLAIN ANALYZE que el planificador lo utiliza y que no ha estimado mal las filas, y tengo presente que cada índice adicional penaliza las inserciones y actualizaciones, por lo que reviso periódicamente cuáles no se usan.

Con bloqueo optimista añado una columna de versión a la fila de stock: leo la unidad con versión 7, calculo la reserva y actualizo con la condición de que la versión siga siendo 7, incrementándola. Si otra transacción se adelantó, la actualización afecta a cero filas y reintento o devuelvo un error de conflicto. Es la opción adecuada cuando la contención es baja, porque no retiene bloqueos y escala bien. Con bloqueo pesimista tomo la fila con SELECT FOR UPDATE antes de calcular, de modo que cualquier otra transacción espera. Lo reservo para casos de contención alta sobre pocas filas, como la venta de entradas de un concierto, donde reintentar constantemente sería peor que esperar. En ambos casos fijo un tiempo máximo de espera de bloqueo para no propagar el atasco, y ordeno siempre los accesos a las filas por el mismo criterio para evitar interbloqueos.

Primero distingo si el problema es de producción o de consumo: comparo la tasa de entrada de mensajes con la de procesado por partición. Si el lag se concentra en unas pocas particiones, suele ser una clave de particionado desequilibrada, con un cliente grande que concentra el tráfico. Si es uniforme, el consumidor va lento y miro dónde se va el tiempo, normalmente una llamada externa síncrona o una escritura sin índice. Las opciones, por orden de coste: aumentar el número de consumidores hasta el número de particiones, ampliar particiones si ya he llegado al límite, procesar por lotes en lugar de mensaje a mensaje, mover el trabajo pesado a un flujo aparte para no bloquear el camino rápido y enviar a la cola de mensajes fallidos aquello que falla de forma reiterada, para que un mensaje envenenado no detenga la partición. Y ajusto max.poll.records y el tiempo de espera para no provocar reequilibrios continuos que empeoren el atasco.

Confirmo el impacto real en el panel antes de tocar nada, porque a veces la alerta es de la propia sonda. Si es real, abro el canal de incidencia y aviso, para que no haya dos personas actuando a ciegas sobre el mismo sistema. Mi primera hipótesis es siempre el último cambio: reviso los despliegues de las últimas horas y, si hay uno reciente, revierto y compruebo si los errores bajan, porque restablecer el servicio es prioritario frente a entender la causa. Si no hubo despliegue, miro dependencias externas, saturación del pool de conexiones y estado del proveedor de pagos. Cuando la tasa vuelve a la normalidad, dejo constancia de la línea temporal y programo el post mortem para el día siguiente. Lo que no hago de madrugada es un cambio de esquema o una optimización improvisada.

Lo trato como un problema de datos, no como un problema de la persona. Comento en la propia pull request con el resultado del EXPLAIN ANALYZE de esa consulta, que hace evidente el recorrido secuencial y el tiempo estimado, y propongo el índice concreto con el orden de columnas justificado, indicando que debe crearse con CONCURRENTLY para no bloquear la tabla. Si la urgencia es alta, ofrezco emparejarme quince minutos en lugar de dejar un hilo de comentarios que alargue el ciclo. Si observo que el patrón se repite en el equipo, propongo una medida estructural: una comprobación en la integración continua que detecte planes con recorrido secuencial sobre las tablas grandes, para que el aviso no dependa de que yo revise el código.

Explico el plan en términos de riesgo y fechas, no en términos técnicos. Propongo la estrategia expand-contract en tres fases: primero añado la columna nueva como opcional y escribo en ambos sitios; después lanzo un proceso de relleno por lotes con pausas para no saturar la base de datos, y verifico la coherencia; por último cambio la lectura a la columna nueva y, solo en una iteración posterior, elimino la antigua. Cada fase es reversible por separado. Con ese enfoque la funcionalidad puede salir en las dos semanas detrás de un feature flag, mientras que la limpieza final queda planificada para después. Si Producto insiste en hacerlo en un solo paso, expongo el escenario concreto: un bloqueo de la tabla de pedidos en hora punta significa checkout caído, y ese coste es mayor que dos semanas adicionales.

No reescribo nada al principio. Empiezo por hacer observable lo que hay: registro estructurado, métricas básicas de latencia y errores por endpoint, y un diagrama sencillo de las dependencias reales, obtenido mirando las llamadas salientes y las tablas que toca. A continuación escribo pruebas de caracterización sobre el comportamiento actual, aunque me parezca incorrecto, para tener una red de seguridad antes de tocar código. Solo entonces introduzco el cambio, aislado tras una interfaz y cubierto por pruebas nuevas. Anoto en un documento breve las trampas encontradas, porque la siguiente persona lo agradecerá. Si detecto deuda grave, la registro con impacto y coste estimados y la llevo a la planificación, en lugar de arreglarla por mi cuenta dentro de la misma entrega.