There's every chance your MX MTA authenticates people against LDAP, uses LDAP again to figure out where to forward the mail to another system for final account storage, then the MDA stores the message on a clustered file system or an object store, then tells the logging system to log the delivery. The LDAP systems for authentication and for where the user's mail lives might be separate instances.

Then the MUA connects to an IMAP proxy which talks to LDAP to authenticate and to determine where the messages for this user are stored (again, possibly different LDAP instances), then connects to an IMAP backend that retrieves the data from a clustered file system or object store. The IMAP proxy, IMAP backend, and MDA are separate systems. The object store is, likewise, a separate system.

Meanwhile some of your users are using a webmail client as their MUA. That talks to an outbound-only MTA and the IMAP proxy, but it may talk directly to LDAP for authentication rather than authenticating to the mail servers first. It can pull user preferences from LDAP. It pulls their contact book from LDAP. These might be three different LDAP instances. I has a calendar app in the same page in another tab, but that talks instead to a separate CalDav server. The folder pane which updates with the number of unread messages in each folder updates through a different backend process on a different web server from the listing of mail in your current folder, which is a separate web server from the one that just fetched the content of the highlighted message into your preview pane.

Meanwhile. half of these systems actually forward through another MTA which makes no final delivery decision itself but scans for spam scoring. Those messages that make it through the filtering get forwarded to another service which only scans for malware. Then those messages which pass go to the system that forwards the mail for final delivery to the user or to the remote party's mx server.

All of these systems need their timestamps correct, so they all talk to an NTP service running alone on a VM or container that does nothing else.

All of these systems send their logs to a central logging cluster via a defined protocol. The logging servers do nothing else.

Just because your mail server might run qmail, Courier, Amavis, SpamAssassin, procmail, and mutt on one box with local storage and local logging doesn't mean that's how mail is done at scale. It's pretty clear to me how if you think of "email" as the application that it is composed of microservices.

A very long comment that ignores the one it purports to reply to...

Microservices are called that because they reside within an app that itself provides a service. Otherwise, of course you could call everything and anything 'microservice' but then the term would become meaningless.

GMail (or any other email offering) is "an app" from many perspectives.

Yes, it is an app. Not a 'microservice'. That's the point.

An app containing many services handling individual, separated aspects of the overall app, connected by queues and standard protocols. Many pieces interchangeable with others. If you'd hide the fact that it's e-mail and wrapped a bunch of HTTP/gRPC around it you could easily sell the same architecture to people as "a messenger build on microservice principles".