Fast inbox experiences come from bounded lists, selective fields, durable cursors, and background hydration, not from downloading every body and attachment on every pass.
Request the smallest fields needed for the inbox view, page deterministically, and hydrate message bodies only when a workflow or user needs them. This reduces provider calls, storage, and exposure of unnecessary message content.
Gmail history IDs and Microsoft Graph delta links encode provider state more reliably than a last-seen timestamp. Keep each cursor scoped to its mailbox or folder and commit it only after corresponding changes are durable.
Use a per-account lease so two workers do not advance the same cursor simultaneously. Apply backpressure across large tenants, honor Retry-After responses, and isolate one failing mailbox from the rest of the queue.
A thin cache still needs tombstones, folder changes, and periodic reconciliation. Measure sync lag and cursor age, then trigger a controlled full rebuild when provider state says incremental recovery is impossible.
Only when the product needs them and its retention policy permits it. A metadata-first cache with on-demand body retrieval is often safer and cheaper.
No. Provider notifications can be incomplete or expire, so low-frequency reconciliation polling is a useful safety net. Tight repeated full-mailbox polling is the problem.
Not yet. Gmail, Microsoft Graph, and IMAP/SMTP connectors are planned. This guide documents the intended architecture and the provider requirements a production release must satisfy.
DewEngine is in development. Real use cases decide what ships first.