Cachea datos que se leen mucho más de lo que cambian y que son caros de producir. Para la invalidación, prefiere un tiempo de vida corto para todo lo que pueda estar algo obsoleto, e invalidación explícita en la escritura para lo que no. Indexa la caché por todo lo que varía el resultado, incluidos el tenant y los permisos, y trata la caché como desechable: el sistema tiene que seguir siendo correcto cuando está vacía.
Por qué lo preguntan los entrevistadores
El caching es de donde salen tanto los bugs de corrección como las caídas, así que el entrevistador busca criterio y no conocimiento de comandos de Redis. Quiere la relación entre lecturas y escrituras como criterio de selección, una estrategia de invalidación explícita, conciencia de que las claves de caché pueden filtrar datos entre usuarios, y la disciplina de tratar la caché como una optimización sin la que el sistema puede sobrevivir.
Cómo estructurar tu respuesta
- Da el criterio: mucha lectura, caro de calcular, tolerable estar algo obsoleto.
- Elige entre un tiempo de vida corto y la invalidación en la escritura.
- Avisa de que las claves de caché pueden filtrar datos entre usuarios.
- Declara que el sistema tiene que funcionar con la caché fría.
Ejemplo de respuesta
Busco tres propiedades: que se lea mucho más de lo que se escribe, que sea caro de calcular y que tolere estar algo obsoleto. Si falla la última, como el saldo de una cuenta, prefiero que sea lento y correcto. Para la invalidación mi opción por defecto es un tiempo de vida corto, porque se cura solo; si un bug hace que me salte una invalidación, el problema se arregla en sesenta segundos en vez de vivir para siempre. Donde la obsolescencia de verdad no es aceptable, invalido en el mismo camino de código que la escritura y acepto el acoplamiento extra. Con lo que más cuidado tengo es con la clave. Todo lo que varía el resultado entra en ella, sobre todo el id de tenant o de usuario, porque el peor bug de caching que he visto fue una respuesta cacheada en la CDN que incluía una cabecera personalizada, y un cliente vio brevemente el nombre de otro cliente. Y siempre pruebo con la caché vaciada, porque si el sistema se cae en frío, no es una caché, es una dependencia.
¿Tienes esta entrevista a la vuelta de la esquina? GhostPilot escucha tu llamada en vivo, detecta la pregunta en cuanto la hacen y pone una respuesta estructurada en tu pantalla en tiempo real. Pruébalo en tu próxima entrevista de práctica, o coge un Session Pass de $29, sin suscripción, para la de verdad.
Mira cómo funcionaPreguntas de seguimiento que puedes esperar
- ¿Cómo evitarías una estampida cuando expira una clave caliente?
- ¿Dónde pondrías la caché: en el proceso, en Redis o en la CDN?
- ¿Cómo mides si una caché está ayudando de verdad?
Más preguntas para Ingeniero de software
Tu entrevistador hará su propia versión de esta. Pega la descripción real del puesto en el Question Predictor gratuito y obtén las 20 preguntas que ese puesto tiene más probabilidades de hacerte, con lo que cada una busca en realidad.
Predecir mis preguntas