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.