Victor Arias
ECO Álbum Brasil is an Android sticker album app running on a cloud backend on AWS: users open packs, buy in the built-in store, swap duplicates and follow their progress with friends, while the team sees usage and errors through monitoring. The system was sized for more than 50,000 active users with a response time of 0.8 seconds.
| Client | ECO Álbum Brasil |
| Industry | Sports collectibles app |
| Service | Cloud Services |
| Stack | Android app, AWS, Cloud backend, Built-in store, Sync and swaps between users, Friends and progress, Monitoring and metrics |
| Duration | 1-2 months |
| Our role | Cloud infrastructure and backend on AWS for the Android app: built-in store, sync and swaps between users, friends and shared progress, and monitoring with usage and error metrics. |
| Published | July 14, 2022 |
A collectibles app is not like a website: its users are inside at the same time and traffic concentrates around the moments of greatest interest. When that happens, infrastructure stops being a technical detail and becomes part of the product.
ECO Álbum Brasil was built on a cloud backend on AWS: a built-in store to buy packs, sync and swaps between users, friends and shared progress, and monitoring with usage and error metrics. The system was sized for more than 50,000 active users with a response time of 0.8 seconds.
The challenge: an app that grows in bursts
Sticker album apps are not used evenly: usage piles up when there is something to open, when a new collection launches or when a sports event brings everyone back. The infrastructure has to hold up on those days without dragging that cost through the rest of the year.
Traffic does not arrive evenly
A server sized for a normal day goes down on the real day. And one sized for the peak gets paid for all 365 days. The cloud solves that contradiction: grow when people arrive and scale back down when they leave.
Swaps have to add up on both sides
Swapping duplicates is what makes the app a daily habit, and also the most delicate operation: two users exchange stickers and both have to see exactly the same result. If the swap is resolved on the phone and someone loses connection halfway through, one of them loses their stickers.
Without metrics, failures show up in the reviews
When an app fails, users do not write an email: they leave a one-star review and uninstall. Without monitoring, that is the first warning the team gets, and it arrives too late. Seeing usage, errors and response time from the inside is what allows fixing things before they show on the outside.
The solution: a cloud backend on AWS
The backend was built on AWS, with infrastructure ready to scale through peaks and monitored from day one. The work focused on what holds the app up: the data of each collection, the store, swaps between accounts and the metrics to see what happens inside.
Everything users do in the app depends on the backend: opening a pack, buying or swapping.
Infrastructure ready for the peaks
The AWS infrastructure was sized to grow when more people come in and shrink when they leave, so the peak of a launch does not turn into an outage or into a fixed cost. That is the difference between holding up on the big day and depending on it.
Built-in store and user progress
Buying packs lives inside the app, on the same backend as everything else: what is purchased shows up in the collection instantly, with no intermediate steps or waiting. Progress and friends rely on those same data, so there are never two truths about what a user owns.
Monitoring to see what happens inside
Usage, errors and response time are tracked from the monitoring dashboard. That turns any incident into a piece of data with context — what is failing, since when and for whom — instead of a vague complaint that has to be reproduced blind.
How we implemented it in one to two months
The project started with measurement: what the app consumes, how many simultaneous users have to be supported and which operations are critical. Those numbers sized the infrastructure and decided what had to be monitored.
The cloud is not sized for what happens on a Tuesday, but for the day everyone comes in at once.
Measure before sizing
Before touching infrastructure we reviewed the app's real behaviour: what it consumes, when it concentrates and how long each operation takes. Sizing without that data means either overpaying or falling short, and in an app both show up on the same day.
Testing the swap, which is where it hurts
Sticker swapping was tested thoroughly, including the awkward cases: two users at once, a connection dropping halfway and retries. It is the operation where a failure does not stay a harmless error message but leaves someone without their stickers.
Results
The project was delivered with the AWS infrastructure, the built-in store, synchronized swaps and monitoring in place. These were the needs and how they were solved:
| Need | How it was solved |
| Holding up through user peaks without outages | AWS infrastructure ready to scale up and back down |
| Buying inside the app | Built-in store on the same backend as the collection |
| Swaps adding up for both users | Sync between accounts resolved in the backend |
| Following progress with friends | Friends and shared progress on the same data |
| Knowing what fails and how long it takes | Monitoring and metrics: 0.8 second response time |
The measured results of the project: more than 50,000 active users and a response time of 0.8 seconds. Both figures go together: the infrastructure exists so the app keeps answering just as fast with a lot of people inside.
What an app with concurrent users needs
If your app concentrates usage around specific moments, these are the points that decide whether it holds up:
- Infrastructure that scales up and back down, so it neither falls over at the peak nor pays for unused capacity.
- Critical operations resolved in the backend, not on the phone: that is where data is guaranteed to add up.
- Sync between users for swaps and shared progress, with each account's state in a single place.
- Purchases integrated in the same backend, so what is paid for shows up instantly.
- Monitoring of usage, errors and timings, which is what prevents finding out about failures through reviews.
- Sizing based on real data, not on an ideal traffic estimate.
If your app falls over exactly when the most people come in, our cloud services page explains how we work, and you can write to us to go through it together.
Frequently asked questions
Why does a collectibles app need the cloud instead of just a server?
Because its traffic does not arrive evenly: it concentrates around launches, draws and sports events, exactly when the most users are inside. Cloud infrastructure lets you grow through those peaks and come back down afterwards, without paying all year for capacity used only a few days.
How are sticker swaps between users kept consistent?
It is the critical part of the system: two users swap and both have to see the same result, even if one loses connection halfway through. Syncing accounts and the state of each collection has to be solved in the backend, not on the phone, because a half-finished swap leaves someone without their stickers.
What can you monitor in an app like this?
Usage, errors and response time. Without those metrics, failures are discovered through app store reviews, once they have already cost users. Monitoring shows what is failing, since when and for whom, so it can be fixed before the problem grows.
How long does it take to set up an app's cloud backend?
This project was delivered in one to two months. The schedule is set by sizing the infrastructure, the built-in store, syncing swaps and progress, and rolling out monitoring.
