Google allows you set input long paragraphs and URLs into a field called "App name" and they then send you an email with the paragraph you entered in (malicious with phishing links) to your inbox. Since this is sent by Google, it's DKIM signed and passes DMARC so you can simply download the entire email and just send it as a raw email to other people and it'll continue to be signed and land in their inboxes.

The other thing is that with these we cannot change the "To" header in the email (not envelope TO (which is where email is delivered to) but rather what shows up in the "To" when the client renders the email) and so the attacker bought a domain that looks like it's google owned "(rand)goog-ssl.com". When looking at emails in your inbox ensure that the "To" is always valid along with the "From".

This is how email-as-infra works, you're sending from a shared pool of their ips and they sign your emails with DKIM and you'll have SPF set up as well on your own.

It should not be used to imply anything else, none of these have anything to do with spam, that's reputation (and yes, having DKIM set-up boosts your reputation but it is not sufficient) and should be "built" up by the domains sending the emails.

"In the case of timelines, each “page” of followers is 10,000 users large and each “page” must be fanned out before we fetch the next page. This means that our slowest writes will hold up the fetching and Fanout of the next page."

Basically means that they block on each page, process all the items on the page, and then move on to the next page. Why wouldn't you rather decouple page fetcher and the processing of the pages?

A page fetching activity should be able to continuously keep fetching further set of followers one after another and should not wait for each of the items in the page to be updated to continue.

Something that comes to mind would be to have a fetcher component that fetches pages, stores each page in S3 and publishes the metadata (content) and the S3 location to a queue (SQS) that can be consumed by timeline publishers which can scale independently based on load. You can control the concurrency in this system much better, and you could also partition based on the shards with another system like Kafka by utilizing the shards as keys in the queue to even "slow down" the work without having to effectively drop tweets from timelines (timelines are eventually consistent regardless).

I feel like I'm missing something and there's a valid reason to do it this way.