Google Cloud Storage vs Redis / ElasticSearch

We're building an application that reads data from an API and displays it in a frontend. Due to API limits, we have to cache the API calls meaning that we save the result of the API calls (both user information (first name, country, email etc.) and big sets of activity log data) in a database and only request new data from the API if the stored data is older than x hours.

This application should also work for multiple users that can log in and see their relevant data. For each user, the application connects to a different API endpoint (e.g. "user1.api.com/data/whatever" and "user2.api.com/data/whatever").

So, in the end there will be two databases. One for caching the API calls of an external tool and another one for the application's user management. However, we are not sure what would be best to use.

Is it generally a good idea to use cloud databases for either caching or user management? As the application will run on Google Container Engine, we could probably use Google Cloud Storage (for caching) and Firebase (for user management). Or should we rather use something like Redis / ElasticSearch (for caching) and something different for the different user data?

I don't know much about Redis/ElasticSearch, but GCS is not really a database-like solution, it is closer to a file storage solution.

If you're looking for database-like storage Google Cloud offers:

• Cloud SQL

• Cloud Bigtable

• Cloud Datastore

• Cloud Spanner

If you expect a modest app traffic or alternating high/low traffic it might be more cost-effective (and simpler) to have a Google App Engine app instead of a GCE-based solution.

StackExchange DevOps Q#827, answer score: 4