La respuesta corta

Una app para una organización de un millón de personas no se dimensiona por su media de uso. Se dimensiona por sus picos, y en este tipo de producto los picos son previsibles: el día del lanzamiento, una convocatoria, una campaña, un proceso electoral, una noticia.

Eso es una ventaja enorme que casi nadie aprovecha. No estás ante un crecimiento incierto: sabes la fecha. Lo que hay que hacer es diseñar para ese día concreto y probarlo antes.

Es el caso de la app oficial de CCOO, para más de un millón de afiliados, con cuatro mil descargas en los primeros días.

El día del lanzamiento es el pico

En una app de consumo el tráfico crece poco a poco. En una app de organización, la comunicación oficial sale un lunes y toda la base se entera a la vez. El resultado: la mayor carga de la vida del producto ocurre antes de que hayas aprendido nada de él.

Consecuencias de diseño:

  • El registro y el primer arranque son el camino crítico, no la pantalla principal. Ahí es donde se concentra todo.
  • Escalonar la comunicación por regiones, por grupos o por letra del apellido es la palanca más barata que existe, y es una decisión de la organización, no técnica. Proponerla es parte del trabajo.
  • Prueba de carga contra el pico previsto, no contra la media. Y con el flujo real de alta, que suele ser el más caro.

Lecturas muchas, escrituras pocas

El patrón de estas apps es muy asimétrico: casi todo el mundo consulta —avisos, documentos, servicios, su ficha— y muy poca gente escribe. Eso se aprovecha:

  • Contenido cacheable en el borde, con invalidación controlada. Si un aviso lo van a leer cuatrocientas mil personas, no debería tocar la base de datos cuatrocientas mil veces.
  • Separar lo personal de lo común. El contenido común se cachea agresivamente; lo personal, no. Mezclarlos en la misma respuesta impide cachear nada.
  • Paginación y respuestas ajustadas al móvil. Una respuesta pensada para una web de escritorio multiplicada por un millón es ancho de banda y batería.

Las notificaciones son un pico en sí mismas

Enviar una notificación a la base entera hace dos cosas a la vez: satura el envío y, sobre todo, provoca que mucha gente abra la app al mismo tiempo. La notificación no es el pico: es el disparador del pico.

Por eso:

  • Envío escalonado por lotes, con la ventana decidida por comunicación y no por el sistema.
  • Que la notificación traiga lo esencial, para que quien solo quiere enterarse no tenga que entrar.
  • Y que la pantalla de destino sea la más barata de servir de toda la app, porque va a recibir el golpe.

Degradar antes que caer

El objetivo no es que nunca falle: es que cuando algo falle, el usuario siga pudiendo hacer lo importante.

  • Modo de solo lectura como plan de contingencia. Si la escritura se satura, que al menos se pueda consultar.
  • Interruptores remotos para apagar funciones concretas sin publicar versión. Es la herramienta que salva un día de lanzamiento.
  • Contenido servido desde caché cuando el origen no responde, con su aviso honesto.
  • Colas para lo que pueda esperar, en lugar de rechazar la petición.

Sin interruptores remotos, el único botón que tienes el día malo es publicar una versión nueva — y eso tarda lo que tarde la revisión de la tienda.

Accesibilidad y dispositivos reales

Una base de un millón de personas incluye toda la variedad posible: teléfonos antiguos, versiones de sistema operativo viejas, conexiones malas y personas con discapacidad. Dos consecuencias:

  • La versión mínima soportada es una decisión de cobertura, no de comodidad del equipo.
  • La accesibilidad es obligatoria en el sector público, y en una organización de este tamaño es además el mayor impacto de la app. Está en accesibilidad UNE-EN 301549.

Medir lo que importa el día D

  • Tasa de finalización del alta, no solo descargas.
  • Errores por paso del registro.
  • Tiempo de respuesta de la pantalla de destino de la notificación.
  • Versiones activas, porque un fallo se arregla publicando y llegando.

Y algo que se olvida: un canal de soporte preparado. En una organización, el día del lanzamiento la centralita recibe llamadas de gente que no consigue entrar, y las preguntas se repiten. Anticiparlas es parte del proyecto.

Antes de estimar

  1. ¿Cuántas personas y en cuántos días se les va a comunicar?
  2. ¿Se puede escalonar la comunicación?
  3. ¿Qué tiene que seguir funcionando si algo se satura?
  4. ¿Hay interruptores remotos y quién los acciona?
  5. ¿Quién atiende el soporte del día uno?

La segunda ahorra más infraestructura que cualquier optimización de código.

Es el tipo de proyecto que hacemos en apps para el sector público: productos donde el reto no es la funcionalidad, sino que un millón de personas lleguen a usarla el mismo día.