I think you may be mixing concerns a bit. Also, the authentication mechanisms for various tools may not necessarily play well with another, and/or you may need different intra-service auth vs. public-facing/customer sessions/tokens. If you need to have disparate tools authenticate to one another with a bearer-type token mechanism, consider Vault. It has excellent support for at least one of the tools you mention (RabbitMQ.)
For flexible token auth, JWTs.
Honestly, it sounds like you are prematurely optimizing.
I would like to build a mobile app that can scale to around 1M users over 1 year. We are currently testing with 100 users without any real load issues.
So would we all. I am building and running a mobile/web app that I intend to grow exponentially, too... but growth doesn't work like that. You're off by many orders of magnitude from 1MM DAU, and any effort you're spending on these questions is far better spent on business development, fundraising, user acquisition... you get the idea.
This isn't to be overcritical or flippant, but to help steer you away from spending engineering dollars or sweat equity (or both) on things you don't need. Granted, I have built my application in a way that I think will scale, however I consciously steer away from solutions that are needlessly over-engineered. I would suggest keeping your options open by building your systems in such a way that you can easily grow and adapt. For instance, consider how your monolith (if you have one) can be separated out into different services that may be able to scale. Consider also that there is a trend in cloud computing away from microservices madness back toward the monolith (the pendulum swings...) so don't get caught up in the hype.
Some of your current stack, e.g. Cloud Run, is also on my stack. I run an application that many only run with attached volume storage (Drupal, don't hate me for being a PHP guy) on Cloud Run with GCS as a persistence layer, along with Cloud SQL. Works great. When I need to scale... I will. I also run an instance of that application on GKE for easier shell access, cron jobs, etc.
TL;DR: Build your tech rapidly and avoid painting yourself into a corner... but realize that you're far more likely to have difficulties building a successful business than you are scaling when the traffic gets crazy.
No shade on the hard work of/on Ionic and Cordova over the years, but they are not the future and you will be going down a dead-end for maintainability going forward. React Native is an excellent bridge for any pre-existing JavaScript/TypeScript skills you might already have from web development.
Flutter is worth considering as a close second but I would recommend RN for the above reasons. Also consider using Expo to ease your build process.
Thank you very much for your recommendation @Brad!
I'll catch up with Expo!
You are mixing concerns. Varnish is a caching reverse proxy, and memcached is an in-memory cache for like, unstructured data. If you're pulling from some sort of backend that speaks HTTP, I guess you could consider Varnish something akin to memcached for pull-through, but keep in mind that in both instances your most significant concern will be cache invalidation rather than getting the cache working to begin with. (Famously one of the two "hard problems in CS.")
