“Dejá de preguntarme si usé Kafka y preguntáme qué hago cuando un servicio empieza a tirar timeouts a las tres de la mañana”, dijo una vez un ingeniero senior describiendo la entrevista que le hubiera gustado tener. La frase circuló como una especie de chiste interno en más de un equipo de plataforma, porque describe exactamente el hueco que casi ninguna entrevista técnica llena: se evalúa el vocabulario, no el criterio.
La obsesión con el stack específico es cómoda porque es fácil de evaluar. Un checklist de frameworks se completa en quince minutos y da la ilusión de objetividad. Pero el desarrollo backend real no vive en esa lista. Vive en las decisiones que alguien toma cuando el sistema está bajo presión, cuando los datos no cuadran, cuando algo que funcionaba perfecto en staging se cae en producción un viernes a la tarde. Ahí se nota quién es senior y quién solamente acumuló certificaciones.
El entrevistador que pregunta por tu stack está haciendo la pregunta equivocada
Preguntar "¿conoces Redis?" tiene una respuesta binaria y no dice nada. Preguntar "¿cuándo NO usarías cache y por qué?" obliga a pensar en trade-offs, en consistencia, en qué pasa si ese dato queda viejo por dos segundos o por dos horas. La primera pregunta filtra por currículum. La segunda filtra por criterio.
Esto no quiere decir que el stack no importe. Importa, y bastante, para el día a día de escribir código que funcione en ese entorno particular. Pero confundir familiaridad con una tecnología con seniority es un error que la industria comete todo el tiempo, sobre todo en procesos de selección diseñados por gente que después no va a trabajar directamente con la persona que están evaluando. Un desarrollador con ocho años de experiencia que nunca tocó el framework de moda puede resolver un problema de escalabilidad en una tarde. Uno con conocimiento superficial de diez tecnologías puede tardar una semana en encontrar por qué su API se cae con tráfico real. La diferencia no está en el vocabulario técnico. Está en el modelo mental de cómo se comportan los sistemas bajo estrés.
Hay algo casi perverso en cómo se diseñan muchas entrevistas técnicas para roles senior: terminan premiando la memoria antes que el razonamiento. Preguntar la sintaxis exacta de un comando o el nombre de un método específico de una librería mide cuánto tiempo pasó esa persona con esa herramienta, nada más. Alguien puede googlear eso en diez segundos el día que lo necesite en el trabajo real. Lo que no puede googlear en diez segundos es el criterio para decidir, en el momento exacto, si conviene romper la consistencia de un dato para no tumbar un servicio completo.
Consistencia o disponibilidad: la decisión que define el desarrollo backend real
Todo sistema distribuido, en algún momento, tiene que elegir. Cuando hay una partición de red o un nodo que no responde, tienes que decidir si el sistema prioriza que todos vean el mismo dato o que el servicio siga respondiendo aunque ese dato esté un poco desactualizado. No hay respuesta correcta en abstracto. Hay una respuesta correcta para ese negocio, ese caso de uso, ese momento.
Un pago no puede quedar en un estado ambiguo. Ahí la consistencia gana, aunque eso signifique que a veces el sistema rechace una operación en lugar de aceptarla con dudas. Un contador de likes puede estar desincronizado por unos segundos sin que nadie note ni le importe. Ahí la disponibilidad gana, porque el costo de bloquear la escritura es mucho más alto que el costo de mostrar un número que no es exacto al milisegundo.
Un desarrollador junior busca la solución que "funcione". Uno senior pregunta primero qué pasa si falla, y diseña la respuesta a esa pregunta antes de escribir la primera línea. Esa pregunta cambia el diseño completo de un sistema de desarrollo backend: qué se replica, qué se bloquea, qué se acepta con inconsistencia temporal y qué nunca, bajo ninguna circunstancia, se acepta con inconsistencia.
Qué pasa cuando un sistema de desarrollo backend falla bajo carga real
Cualquiera puede diseñar para el caso feliz. El código que asume que la base de datos responde rápido, que la red no se cae, que el usuario nunca manda un payload raro, ese código lo escribe cualquiera con dos años de experiencia y un tutorial bien seguido. El código que asume que todo eso va a fallar, tarde o temprano, y que sigue funcionando (o falla de forma controlada) cuando pasa, ese es el que separa niveles.
Pensar en fallas bajo carga real significa preguntarse cosas concretas. ¿Qué pasa si este servicio recibe diez veces el tráfico esperado en un pico? ¿El sistema se degrada de forma controlada o se cae entero? ¿Hay un circuit breaker que corta la llamada a un servicio lento antes de que ese servicio tumbe a todos los que dependen de él, o un timeout mal configurado va a dejar threads colgados hasta que el proceso completo se quede sin memoria?
Los sistemas no fallan de forma prolija. Fallan en cascada, con un servicio lento que satura las conexiones de otro, que satura las de otro más, hasta que lo que empezó como un problema aislado tumba media plataforma. Diseñar para eso no es pesimismo. Es simplemente asumir que la infraestructura, la red y el tráfico se van a comportar mal en algún momento, y que el trabajo es que ese momento cueste lo menos posible.
Qué se cachea, por qué, y qué pasa el día que el cache miente
Cachear parece una optimización inocente. Guardas un dato, ahorras una consulta, todo más rápido. Pero cada cache es una apuesta sobre cuánto puede envejecer un dato antes de que eso le cueste algo al negocio. Esa apuesta tiene un nombre técnico (invalidación) y es, sin exagerar, uno de los problemas más subestimados del desarrollo backend.
Cachear el precio de un producto sin pensar en cuándo se actualiza ese cache puede hacer que un cliente compre algo a un precio que ya no existe. Cachear el estado de una sesión sin invalidar correctamente puede hacer que un usuario vea datos de otro usuario, algo que además de un bug es un problema serio de seguridad. El cache mal diseñado no rompe el sistema de forma ruidosa. Rompe la confianza en los datos de forma silenciosa, y eso tarda semanas en detectarse porque todo "parece" funcionar.
Un desarrollador senior no pregunta "¿esto se puede cachear?". Casi todo se puede cachear. Pregunta "¿qué tan grave es que este dato esté desactualizado por X segundos, y quién paga ese costo si me equivoco?". Esa pregunta obliga a mirar el negocio, no solamente el código, y ahí es donde mucha gente con conocimiento técnico profundo se queda corta: sabe implementar Redis, pero nunca pensó en el impacto de negocio de una invalidación mal calculada.
Nada de esto se resume en una lista de tecnologías, porque no es conocimiento de tecnologías: es criterio de sistema, la capacidad de anticipar cómo se va a comportar algo que todavía no existe, bajo condiciones que todavía no pasaron. Ese criterio se construye viendo sistemas fallar en producción, no leyendo documentación.
Por eso un currículum con quince tecnologías listadas dice poco, y veinte minutos hablando de un incidente real dicen todo. La pregunta que separa a alguien senior no es qué frameworks conoce. Es si, cuando algo se rompió, entendió por qué se rompió o solamente lo arregló.
Los frameworks cambian cada dieciocho meses. El criterio, no.
