MySQL database design for Twitter-like timeline
Details not yet spelled out for the schema:

PKs -- What datatype?  INT UNSIGNED (4 bytes) tops out at 4 billion; think about whether you need to go above that or can shrink the size.

Collations -- For inclusion of Chinese and Emoji, be sure to use utf8mb4.

Password -- You should probably not store the plain-text password, but rather the encrypted version.

Latitude &amp; Longitude -- How much precision is needed?  What queries will be applied.  This area can lead to some terribly inefficient code.  Your choices today impact your ability to even use lat/lng without a major rewrite, especially for your item 5.  http://mysql.rjweb.org/doc.php/latlng#representation_choices  and http://mysql.rjweb.org/doc.php/find_nearest_in_mysql

Table: followers -- Does "x follows y" imply that "y follows x"?  The answer to this has an impact all the way back to the table definition.

"reference_id  (Can be report_id or follower_id or message_sender_id)" -- This is not easy to implement.  You may have to re-think the requirements.  Ponder whether to do it as 3 tables that are UNIONed together.

If you are talking about "massive scale", you will need to allow for "sharding".  I recommend postponing that until later -- but plan for a major rewrite in the near future.

If things will be "deleted", will they be "soft" or "hard" deletes or some form of "archiving".  If the quantity is small, this question does not matter; if it is large, it impacts performance and may resort to Partitioning, which is a big schema change.

For performance, consider turning off FKs for production, but keeping them in development.  Be sure to keep the indexes that are implicitly created for FKs.

Etc.