Story: A Scaling, Cost-effective Infrastructure for the Data-intensive App "Quotely"

About Quotely

The wallpaper app "Quotely" is developed by ICAP Group GmbH from Heilbronn, Germany. The app was in alpha development state at the time of the project.

The Challenge: Data-Transfer Costs with Google Firebase

Google Firebase is a cloud-based development platform that focuses on mobile applications and is popular with startups and for "rapid prototyping" thanks to its FREE tier pricing.

It supports several different key components, including authentication, monitoring, machine learning and data storage. For storage, it offers three key services:

• Firebase Realtime,
• Cloud Firestore
• Firebase Cloud Store

Realtime and Firestore are both cloud-hosted NoSQL database systems (DBaaS) with offline support tailored to the mobile use case. Firebase Cloud Store, on the other hand, is a front-end for standard Google Cloud storage supported with SDKs. It also supports server-side processing and integrates with Firebase authentication. Unlike the two databases, it does not have offline support, but it is supported by a content delivery network (CDN).

The "No-cost Spark Plan" is a free plan with limits on the number of accesses, storage, and network.

However, based on the business plan and the initial success of the "Quotely" app, the first significant "network egress" costs for outgoing network traffic arose shortly after release. Here the free tier is capped at 10 GiB/month, after which the usual Google Cloud network prices apply.

Typically, network prices are not the main cost driver, and are in the 10% range of the total cost for cloud-hosted databases and DBaaS offerings.
However, in this use case of a data-intensive freemium app with "sharing" of high-resolution images, this was the main cost factor.

The Solution: Technology Analysis & Cost Scenarios

The problem was solved in several stages. First, the technology stack and architecture were analyzed. In the second step, a cost calculation was made based on the existing access patterns and workloads in line with the business plan, and alternative scenarios were selected and compared in terms of cost.

Phase 1: System Analysis

The existing software architecture, based on the Google Firebase technology stack, was analyzed and discussed with the CTO of ICAP Group. In addition, previous user behavior was analyzed, and an application-specific workload was modeled.

Phase 2: Cost Calculation

Based on the user behavior and workload, a scenario analysis for the development of the costs per user could be estimated. This was synchronized with the existing business plan to compare costs and revenues. This led to the need to identify alternative technologies or architecture solutions and compare them in terms of cost.

Phase 3: Technology Comparison

Since Google Firebase consists of a whole stack of coordinated technologies, alternative solutions had to be found for various sub-areas.
Obviously, the solutions and building blocks of the other cloud hyperscalers, which operate a similar but not identical pricing model, were obvious here. But also CDNs that offer special solutions for large data transfers.
These alternative solutions were costed individually and compared with each other, similarly as in phase 2.

The Results: Data-driven Guidance

Calculating costs over time showed clear recommendations for action that can be taken as growth progresses and certain milestones in user numbers are reached to reduce costs in the future.

For this network-intensive workload, for example, AWS would likely see 25% lower costs over time. Moreover, from a scale of 50,000 users, the use of a CDN makes sense from a cost perspective in this case.

Furthermore, in addition to technology recommendations, it was also possible to make clear recommendations for action on an architecture basis that can reduce costs in general, regardless of the technology. For example, Google Firebase does not include native caching and compression schemes.

Ideally, calculations are reviewed at the time of milestone achievement with a current workload and user behavior. With new features, customer groups, and data size, this certainly can and will be the case.

We wish ICAP Group continued success with their wallpaper app "Quotely", and thank them for their trust!