Varias pantallas necesitan los mismos datos del servidor y se están pidiendo una y otra vez. ¿Cómo lo resolverías?

Pon los datos en una capa con caché indexada por petición en lugar de en el estado de los componentes. Una librería de queries deduplica peticiones concurrentes con la misma clave, sirve los datos de caché al instante mientras revalida en segundo plano, y te da un único sitio donde invalidar tras una mutación. En el lado del servidor, cachear a nivel de petición más precargar en la ruta hace que el cliente muchas veces ya tenga los datos antes de que el componente se monte.

La causa raíz suele ser que los datos se están tratando como estado del componente, así que cada pantalla tiene su propia copia y su propia petición. Los muevo a una caché de queries indexada por algo con sentido, como el nombre del recurso más el id. Una vez indexados, tres componentes pidiendo lo mismo durante una pasada de render producen una sola petición de red, y la segunda pantalla se pinta al instante desde la caché mientras una revalidación ocurre discretamente por detrás. Configuro el tiempo de caducidad por recurso y no de forma global, porque el perfil de un usuario puede estar caducado durante minutos y el estado de un pedido en vivo no. Las mutaciones entonces invalidan claves concretas en vez de todo, y mantengo los constructores de claves en un solo módulo para que nadie invente una clave ligeramente distinta y rompa la caché sin querer. Si el framework lo permite, precargo en la ruta o cargo en el servidor, de forma que los datos ya van en camino antes de que el componente se monte, que es lo que de verdad elimina la cascada en vez de esconderla detrás de un spinner.