Servicios cloud para app de coleccionables: ECO Álbum Brasil

Una app de coleccionables no se parece a una web: tiene a sus usuarios dentro al mismo tiempo y el tráfico se concentra en los momentos de más interés. Cuando eso pasa, la infraestructura deja de ser un detalle técnico y se convierte en parte del producto.

ECO Álbum Brasil se montó sobre un backend en la nube en AWS: tienda integrada para comprar sobres, sincronización e intercambios entre usuarios, amigos y progreso compartido, y monitorización con métricas de uso y errores. El sistema se dimensionó para más de 50.000 usuarios activos con un tiempo de respuesta de 0,8 segundos.

El reto: una app que crece a golpe de picos

El uso de una app de barajitas no se reparte de forma uniforme: se acumula cuando hay algo que abrir, cuando se lanza una colección o cuando un evento deportivo devuelve a todo el mundo a la app. La infraestructura tiene que aguantar esos días sin arrastrar ese coste el resto del año.

El tráfico no llega repartido

Un servidor dimensionado para el día normal se cae en el día de verdad. Y uno dimensionado para el pico se paga entero los 365 días. La nube resuelve esa contradicción: crecer cuando llega la gente y volver a bajar cuando se marcha.

Los intercambios tienen que cuadrar en los dos lados

Intercambiar repetidas es lo que hace que la app se use a diario, y también la operación más delicada: dos usuarios cambian barajitas y los dos tienen que ver exactamente el mismo resultado. Si el intercambio se resuelve en el teléfono y alguien pierde la conexión a mitad, uno de los dos pierde sus barajitas.

Sin métricas, los fallos se descubren en las reseñas

Cuando una app falla, el usuario no escribe un correo: deja una reseña de una estrella y desinstala. Sin monitorización, ese es el primer aviso que recibe el equipo, y llega demasiado tarde. Ver el uso, los errores y el tiempo de respuesta por dentro es lo que permite corregir antes de que se note fuera.

La solución: backend en la nube sobre AWS

El backend se montó sobre AWS, con la infraestructura preparada para escalar en los picos y monitorizada desde el primer día. El trabajo se centró en lo que sostiene la app: los datos de cada colección, la tienda, los intercambios entre cuentas y las métricas para ver qué ocurre por dentro.

Infraestructura preparada para los picos

La infraestructura en AWS se dimensionó para crecer cuando entra más gente y reducirse cuando se marcha, de modo que el pico de un lanzamiento no se convierta en una caída ni en un coste fijo. Es la diferencia entre aguantar el día grande y depender de él.

Tienda integrada y progreso del usuario

La compra de sobres vive dentro de la app, sobre el mismo backend que el resto: lo que se compra se refleja al instante en la colección, sin pasos intermedios ni esperas. El progreso y los amigos se apoyan en esos mismos datos, así que no hay dos verdades sobre lo que tiene cada usuario.

Monitorización para ver qué pasa dentro

Uso, errores y tiempo de respuesta se siguen desde el panel de monitorización. Eso convierte cualquier incidencia en un dato con contexto —qué falla, desde cuándo y a quién— en lugar de una queja genérica que hay que reproducir a ciegas.

Cómo lo implementamos en uno a dos meses

El proyecto empezó por medir: qué consumo tiene la app, cuántos usuarios simultáneos hay que sostener y qué operaciones son críticas. Con esos números se dimensionó la infraestructura y se decidió qué había que monitorizar.

Medir antes de dimensionar

Antes de tocar la infraestructura se revisó el comportamiento real de la app: qué consume, cuándo se concentra y cuánto tarda cada operación. Dimensionar sin esos datos es pagar de más o quedarse corto, y en una app las dos cosas se notan el mismo día.

Probar el intercambio, que es donde duele

El intercambio de barajitas se probó a conciencia, incluidos los casos incómodos: dos usuarios a la vez, conexión que se corta a mitad y reintentos. Es la operación donde un fallo no se queda en un mensaje de error, sino en barajitas perdidas para alguien.

Resultados

El proyecto se entregó con la infraestructura en AWS, la tienda integrada, los intercambios sincronizados y la monitorización en marcha. Estas fueron las necesidades y cómo se resolvieron:

Los resultados medidos del proyecto: más de 50.000 usuarios activos y un tiempo de respuesta de 0,8 segundos. Los dos datos van juntos: la infraestructura existe para que la app siga respondiendo igual de rápido con mucha gente dentro.

Qué necesita una app con usuarios concurrentes

Si tu app concentra el uso en momentos concretos, estos son los puntos que deciden si aguanta:

• Infraestructura que escale y vuelva a bajar, para no caerse en el pico ni pagar capacidad que no se usa.
• Operaciones críticas resueltas en el backend, no en el teléfono: es donde se garantiza que los datos cuadren.
• Sincronización entre usuarios para intercambios y progreso compartido, con el estado de cada cuenta en un único sitio.
• Compras integradas en el mismo backend, para que lo que se paga se refleje al instante.
• Monitorización de uso, errores y tiempos, que es lo que evita enterarse de los fallos por las reseñas.
• Dimensionado a partir de datos reales, no de una estimación de tráfico ideal.

Si tu app se cae justo cuando más gente entra, en la página de servicios cloud contamos cómo trabajamos, y puedes escribirnos para revisarlo juntos.

Preguntas frecuentes

¿Por qué una app de coleccionables necesita nube y no basta con un servidor?

Porque su tráfico no llega repartido: se concentra en lanzamientos, sorteos y eventos deportivos, justo cuando más usuarios hay dentro. Una infraestructura en la nube permite crecer en esos picos y volver a bajar después, sin pagar todo el año por capacidad que solo se usa unos días.

¿Cómo se sostiene el intercambio de barajitas entre usuarios?

Es la parte crítica del sistema: dos usuarios intercambian y los dos tienen que ver el mismo resultado, aunque uno pierda la conexión a mitad. La sincronización entre cuentas y el estado de cada colección tienen que resolverse en el backend, no en el teléfono, porque un intercambio a medias deja a alguien sin sus barajitas.

¿Qué se puede monitorizar en una app así?

Uso, errores y tiempo de respuesta. Sin esas métricas los fallos se descubren por las reseñas de la tienda de aplicaciones, cuando ya han costado usuarios. Con monitorización se ve qué está fallando, desde cuándo y a quién, y se corrige antes de que el problema crezca.

¿Cuánto tarda montar el backend en la nube de una app?

Este proyecto se entregó en uno a dos meses. El calendario lo marcan el dimensionado de la infraestructura, la tienda integrada, la sincronización de intercambios y progreso, y la puesta en marcha de la monitorización.