Comprobación de fetch de Remote Config antes de que tu app de fin de semana sufra limitación

Publicas una app de fin de semana con un kill switch, luego notas Remote Config en la consola de Firebase. Las flags son prácticas, pero los cálculos de fetch te hacen preguntarte si una app pequeña puede convertirse silenciosamente en una factura.

Con el intervalo mínimo de fetch predeterminado de 12 horas, un dispositivo puede hacer fetch como máximo dos veces al día, lo que sitúa a 50,000 usuarios activos diarios como el punto de equilibrio del plan gratuito con ese valor predeterminado. El plan gratuito cubre 100,000 solicitudes de fetch al día, por lo que la mayoría de los proyectos no deberían verse afectados. La mayoría de los proyectos secundarios se quedan como proyectos secundarios, y está bien. Una comprobación breve resuelve la preocupación antes de que comience la limitación o la facturación.

Remote Config inicia su modelo de precios pay-as-you-go el 1 de septiembre de 2026. El número a vigilar es el volumen diario de fetch, no el número de usuarios. Un fetch ocurre cuando una app de cliente o un servidor de backend solicita al servidor de Remote Config valores de parámetros actualizados, incluyendo llamadas como fetch() o fetchAndActivate() desde SDKs de cliente. Cuando tu app llama a la biblioteca de cliente al inicio, al reanudar y después de cada deep link, el número puede crecer más rápido que tu número de usuarios.

El tope gratuito se basa en fetches, no en usuarios

El intervalo predeterminado hace que los cálculos sean favorables para apps pequeñas. Evita que cada dispositivo convierta un día normal en un flujo de solicitudes. Por debajo del punto de equilibrio, los cálculos juegan a tu favor. Por encima, las flags están haciendo trabajo real y la pregunta del coste también lo es.

Usa el día más reciente con más actividad, no una media tranquila. Un día de lanzamiento, una campaña de push o un bug que relanza la app pueden elevar el número por encima de tu número normal de usuarios. La comprobación es una forma de ver ese pico antes de que se convierta en una sorpresa de cuota. Una app que sigue siendo pequeña puede no mostrar la diferencia. Una app en crecimiento convierte esa diferencia en el punto central de la comprobación.

Una comprobación breve convierte la preocupación en un número

Mantén esta lista en el README junto al script de despliegue. El orden importa porque convierte una preocupación vaga en un número. Es lo suficientemente breve para ejecutarla antes de una release, y lo suficientemente específica para decirte qué cambiar.

• Lee el total diario de fetch de Remote Config en la consola de Firebase.
• Multiplica los usuarios activos diarios por el máximo de fetches por dispositivo y por día.
• Compara ese producto con la cuota diaria.
• Comprueba el intervalo mínimo de fetch y sube cualquier valor de desarrollo que esté por debajo del valor de producción.
• Si el proyecto está en Spark y supera el tope, ten en cuenta que el servidor limita las solicitudes adicionales por encima del tope diario después de un período de gracia de 30 días.

La idea es saber en qué escenario estás: a salvo, subir el intervalo, o planificar para Blaze y el cronograma del período de gracia. La comprobación es breve porque el riesgo es acotado: una app pequeña empieza a comportarse como un producto grande antes de que la consola te lo diga.

El intervalo de fetch es la primera palanca

Cuando la estimación se acerca a la cuota, la primera solución suele ser el intervalo. Cambiar el intervalo es la palanca más barata porque modifica la frecuencia con la que la app pregunta, no lo que pregunta. Un intervalo más corto durante el desarrollo puede hacer que un puñado de testers se comporte como una multitud. Restaura el intervalo de producción antes de compartir el build. Ese cambio puede mantener una app pequeña por debajo del límite sin tocar el código que lee las flags.

Superar el tope no es un bloqueo permanente hoy en día. Aún puedes reducir el volumen de fetch o pasar a un plan de pago cuando la app justifique el gasto.

Bajo el plan Blaze, Remote Config cuesta $0.06 por cada 10,000 solicitudes hasta 10 millones de solicitudes, y $0.01 por cada 10,000 solicitudes después de 10 millones. Para un proyecto de fin de semana, eso suele ser una factura pequeña, pero es una factura. Una app en etapa temprana puede estar mejor atendida con los cálculos de intervalo y número de usuarios.

Los proyectos existentes tienen una palanca de cronograma. Actualizar antes del 15 de noviembre de 2026 extiende el período de gracia a cinco meses, con la facturación iniciándose el 1 de febrero de 2027. Esa ventana puede comprar tiempo para un proyecto que no está listo para pagar, y puede hacer que el cambio sea menos abrupto para uno que sí lo está.