Email Connections That Survive Auth Expiry
Email in a multi-tenant app has two readers and several providers with different login lifetimes. This is how I kept sync reliable and what happens after three failures.
Email looks like a solved problem until one product has to support several providers, several ways of signing in, and two very different consumers of the same mailbox. This was one of the hardest problems on RE/AMP, the multi-tenant platform I lead.
The two readers
Background workers poll IMAP to bring in new messages. At the same time, live API requests fetch email for the person looking at the screen.
Both need a working connection to the same account, and they run in different execution contexts. A design that only suits one of them breaks the other.
The two kinds of login
Some providers allow OAuth connections that stay valid for nearly an hour. Others rely on app passwords, where connections often need to be re-established in under 30 minutes. The product had to handle legacy app-password authentication while planning for OAuth connections.
That difference matters because connection lifetime decides how often you reconnect. A design built around the long lifetime fails constantly on the short one.
What the design had to do
The system could not let an expiring connection interrupt email sync, and it could not make messages unavailable to users while a connection was refreshed. So connection management, authentication handling, and access had to be coordinated across the worker and the live request path.
The point was to treat the connection as something that is expected to expire and be replaced, not as something that is set up once and kept alive.
When authentication really fails
Short lifetimes are normal, but a revoked login is different. If authentication fails three times in a row, I set the email connection to unusable and flag the user to update their credentials, since their access has likely been revoked.
Pausing matters for two reasons. It stops the workers from hammering a provider with bad credentials, and it tells the user clearly what to fix instead of leaving them with a mailbox that quietly stopped syncing.
Why this was worth the effort
It combined third-party integration, infrastructure, and application architecture in one place. The result had to be flexible enough for different providers and still dependable in production.
If you are building something similar, decide early how many readers a mailbox has, write down each provider’s connection lifetime, and choose a clear rule for when to stop retrying.
Related
This work is part of the RE/AMP case study. The API integrations service covers this kind of work.