Preguntas de entrevista Desarrollador backend

Empiezo por los consumidores de la API antes de pensar en la implementación. Las primeras preguntas que hago son: quién va a llamar a esto, qué datos necesitan realmente, y qué operaciones tienen sentido desde una perspectiva de recursos. A partir de ahí diseño en torno a recursos y verbos HTTP estándar, manteniendo las URLs basadas en sustantivos y usando los códigos de estado de forma consistente en lugar de enterrar los errores dentro de respuestas 200. Documento a medida que avanzo usando OpenAPI porque un esquema que existe desde el primer día evita que la API se desvíe de su contrato. También versiono desde el principio: añadir /v1/ al path base no cuesta nada al principio y ahorra un trabajo de migración doloroso más adelante. Antes de finalizar cualquier API, la reviso con los equipos que la van a consumir, porque la mejor señal de que un diseño es correcto es que el consumidor puede escribir su código de integración sin necesidad de hacerme preguntas de seguimiento.

La seguridad es una preocupación de diseño, no un paso de revisión al final. Mi punto de partida es el OWASP Top 10: inyección SQL, autenticación rota, exposición excesiva de datos, etc. No son vectores de ataque exóticos; son los que causan la mayoría de las brechas reales. En la práctica esto significa consultas parametrizadas en todas partes, ningún secreto en el código ni en los logs, validación JWT con expiración correcta, y validación de entradas en la frontera de la API en lugar de confiar en el cliente. Para los datos sensibles aplico el principio del mínimo privilegio a nivel de base de datos: los servicios solo tienen acceso a las tablas que necesitan. También integro limitación de velocidad en los endpoints públicos para prevenir abusos. Animo a los miembros del equipo a señalar problemas pronto, porque una vulnerabilidad detectada en una revisión de código cuesta mucho menos que una descubierta en producción.

Abordo los problemas de rendimiento igual que cualquier problema de depuración: medir antes de cambiar nada. Lo peor que puedes hacer es optimizar algo que no es el verdadero cuello de botella. Mi primer paso es siempre identificar el camino lento usando herramientas de profiling o datos de APM. En la mayoría de los casos la respuesta es la base de datos: los índices faltantes, los patrones N+1 o cargar más datos de los que el consumidor necesita son responsables de la mayoría de las ralentizaciones de backend que he visto. Una vez identificado el cuello de botella, busco primero la solución de menor coste. Añadir un índice lleva minutos y puede mejorar una consulta en órdenes de magnitud. Si el problema es estructural, reviso el cacheo con Redis para datos de lectura intensiva que no cambian con frecuencia, y el procesamiento asíncrono para operaciones que no necesitan ser síncronas. Siempre mido antes y después de un cambio y documento el resultado para que el equipo entienda lo que ganamos.

La IA ha cambiado mi flujo de trabajo diario de formas concretas. Para el boilerplate: crear un nuevo servicio, scaffoldear una suite de tests, escribir migraciones, la IA me da un primer borrador sólido en minutos que luego reviso y ajusto. El valor no es solo la velocidad; reduce la carga cognitiva de cambiar entre la lógica que estoy diseñando y la sintaxis y el scaffolding necesarios para expresarla. Para depurar bases de código desconocidas o rastrear un mensaje de error que no he visto antes, la IA suele encontrar la causa probable más rápido que una búsqueda. Donde tengo más cuidado es con el código sensible a la seguridad: nunca pego secretos o datos personales en un modelo público, y siempre reviso cuidadosamente cualquier lógica de autenticación o autorización generada por IA, porque los errores sutiles en esas áreas tienen las mayores consecuencias. También uso la IA para generar casos de prueba, pidiéndole que considere casos límite que podría haber pasado por alto, lo que ha detectado errores reales antes de que llegaran a producción.

Nuestro servicio de procesamiento de pagos comenzó a generar errores 500 intermitentes un viernes por la tarde, afectando aproximadamente al 3% de las transacciones. Me uní a la llamada de incidente, revisé los logs, y en diez minutos identifiqué que los errores se agrupaban alrededor de una réplica de base de datos específica que había quedado rezagada en la replicación. La causa raíz era una consulta de larga duración introducida en un despliegue anterior ese día. Coordiné con el DBA de guardia para redirigir el tráfico lejos de la réplica rezagada mientras hacíamos rollback de la consulta. El incidente duró 40 minutos desde la detección hasta la resolución. Durante todo el proceso, di actualizaciones cada cinco minutos para que el equipo de soporte pudiera gestionar las comunicaciones con los clientes en paralelo. Tras el incidente, escribí un post-mortem, añadí una alerta de retraso de replicación que no teníamos, y añadí el análisis de rendimiento de consultas a nuestra lista de comprobación previa al despliegue.

Necesitábamos añadir notificaciones en tiempo real a nuestra plataforma. Dos enfoques eran viables: polling desde el cliente cada pocos segundos, o una conexión WebSocket por usuario. El polling era más sencillo de implementar y más fácil de escalar horizontalmente. Los WebSockets ofrecían una mejor experiencia de usuario pero añadían complejidad significativa: estado de conexión, lógica de reconexión y configuración del balanceador de carga. Dado nuestro base de usuarios de unos 50.000 activos en ese momento, el polling habría añadido carga significativa en la base de datos por una mejora de UX relativamente pequeña. Elegimos WebSockets pero limitamos la implementación inicial a un subconjunto de tipos de notificaciones de alto valor. Esto nos permitió validar la infraestructura antes de desplegarlo en todas partes. La decisión clave fue construir una capa de abstracción de notificaciones para poder cambiar el mecanismo subyacente sin reescribir cada consumidor, lo que mantuvo la decisión reversible.

Heredé un servicio de informes que ejecutaba trabajos batch diarios y frecuentemente agotaba el tiempo de espera para nuestros clientes más grandes, a veces durante cuatro horas. Perfilé las consultas más lentas y encontré dos problemas: una consulta cargaba tablas enteras en memoria y filtraba en el código de la aplicación en lugar de en SQL, y un trabajo recurrente se ejecutaba sin paginación y agotaba la memoria en conjuntos de resultados grandes. Reescribí la consulta problemática para usar agregados de base de datos y filtros con índices, y añadí paginación por cursor al trabajo batch. El resultado fue una reducción del tiempo de ejecución de cuatro horas a menos de 20 minutos para las cuentas más grandes. También añadí una alerta de tiempo límite para saber antes si un trabajo futuro estaba tendiendo en la dirección equivocada.

SQL es mi opción por defecto para la mayoría de los datos de aplicación porque la integridad relacional, las transacciones ACID y las consultas ad hoc son propiedades valiosas que no quiero sacrificar sin una buena razón. Considero NoSQL cuando se cumple una de estas tres condiciones: los datos tienen verdaderamente forma documental y no se benefician de la normalización (un CMS con esquema variable es un buen ejemplo); los patrones de acceso son simples y conocidos de antemano y necesito escala horizontal más fácil de lograr con un almacén de clave-valor o documental; o estoy construyendo un caso de uso de series temporales o grafos que no se adapta bien a las tablas relacionales. Lo que intento evitar es elegir NoSQL por razones de rendimiento sin medir primero si la solución SQL es realmente demasiado lenta. Las decisiones prematuras de arquitectura de base de datos son costosas de revertir.

El cacheo es un compromiso entre consistencia y rendimiento, así que empiezo preguntando si el caso de uso tolera datos desactualizados, y si es así, durante cuánto tiempo. Para datos que cambian con poca frecuencia y son leídos por muchos usuarios como configuración, datos de referencia o perfiles públicos, un patrón cache-aside con un TTL corto es generalmente la elección correcta y Redis es mi herramienta por defecto. Para datos donde la consistencia importa como saldos de cuentas o recuentos de inventario, evito el cacheo en la capa de aplicación y me centro en optimizar la consulta. Siempre soy cuidadoso con la invalidación del caché: cuando ocurre una escritura, ¿cómo nos aseguramos de que el caché no sirva datos desactualizados? Mantengo la lógica de invalidación simple y explícita en lugar de confiar solo en el TTL para datos que se modifican. También instrumento las tasas de aciertos del caché: un caché por debajo del 70% generalmente no vale lo que cuesta y puede estar ocultando un problema de índice.

Lo abordo como un problema de análisis de carga. La pregunta que quiero responder antes de diseñar nada es: ¿dónde se rompe el sistema bajo carga, y cuál es el coste de cada solución? Empiezo identificando el cuello de botella probable: para la mayoría de las aplicaciones web es el pool de conexiones a la base de datos o una operación síncrona única en el camino crítico. Para un escenario de pico pienso en tres palancas. Primero, escala horizontal: ¿puedo añadir instancias detrás de un balanceador de carga sin estado mutable compartido? Esto requiere servicios sin estado y el estado de sesión almacenado externamente. Segundo, desacoplamiento por cola: ¿puedo mover el trabajo que no necesita ser síncrono a una cola para que el tiempo de respuesta de la API sea rápido incluso bajo carga? Tercero, réplicas de lectura y cacheo: ¿puedo absorber el tráfico de lectura sin tocar la base de datos primaria? Una decisión de arquitectura real necesita datos de pruebas de carga para validar las suposiciones.