ایمیل‌های ورودی در متعادل‌کننده بار SMTP وارد می‌شوند.
متعادل‌کننده بار، ترافیک را بین سرورهای SMTP توزیع می‌کند. سیاست پذیرش ایمیل می‌تواند پیکربندی و در سطح اتصال SMTP اعمال شود. برای مثال، ایمیل‌های نامعتبر برگردانده می‌شوند تا از پردازش ایمیل غیرضروری جلوگیری شود.
اگر پیوست یک ایمیل خیلی بزرگ باشد که نتوان آن را در صف قرار داد، می‌توانیم آن را در فضای ذخیره‌سازی پیوست‌ها در (S3) قرار دهیم.
ایمیل‌ها در صف ایمیل‌های ورودی قرار می‌گیرند. صف، workerها پردازش ایمیل را از سرورهای SMTP جدا می‌کند تا بتوان آنها را به طور مستقل مقیاس‌پذیر کرد. علاوه بر این، صف به عنوان بافر عمل می‌کند در صورتی که حجم ایمیل افزایش یابد.
workerها پردازش ایمیل مسئول انجام بسیاری از وظایف هستند، از جمله فیلتر کردن ایمیل‌های spam، متوقف کردن ویروس‌ها و غیره. مراحل بعدی فرض می‌کنند یک ایمیل از اعتبارسنجی عبور کرده است.
ایمیل در فضای ذخیره‌سازی ایمیل، کَش و فضای ذخیره‌سازی اشیاء (object data store) ذخیره می‌شود.
اگر گیرنده در حال حاضر آنلاین است، ایمیل به سرورهای بلادرنگ ارسال می‌شود.
سرورهای بلادرنگ، سرورهای WebSocket هستند که به کاربران امکان می‌دهند تا ایمیل‌های جدید را در زمان واقعی دریافت کنند.
برای کاربران آفلاین، ایمیل‌ها در لایه ذخیره‌سازی ذخیره می‌شوند. زمانی که یک کاربر دوباره آنلاین می‌شود، کلاینت وب‌میل از طریق RESTful API به سرورهای وب متصل می‌شود.
سرورهای وب ایمیل‌های جدید را از لایه ذخیره‌سازی می‌کِشند و آنها را به کلاینت برمی‌گردانند.
نمودار زیر مسیر ارسال ایمیل را نشان می‌دهد.
1. یک کاربر ایمیلی را در وب‌میل می‌نویسد و دکمه "ارسال" را می‌زند. درخواست به توزیع‌کننده بار ارسال می‌شود.
2. توزیع‌کننده بار اطمینان حاصل می‌کند که درخواست‌های ارسال ایمیل از محدودیت نرخ تجاوز نمی‌کند و ترافیک را به وب سرورها هدایت می‌کند.
3. وب سرورها مسئول موارد زیر هستند:
اعتبارسنجی اولیه ایمیل. هر ایمیل وارد شده در برابر قواعد از پیش تعریف شده مانند محدودیت اندازه ایمیل بررسی می‌شود.
بررسی اینکه آیا دامنه آدرس ایمیل گیرنده با فرستنده یکسان است یا خیر. اگر یکسان باشد، داده‌های ایمیل مستقیماً در ذخیره‌سازی، کَش و object store وارد می‌شوند. گیرنده می‌تواند ایمیل را مستقیماً از طریق RESTful API دریافت کند. نیازی به رفتن به مرحله 4 نیست.
4. صف پیام‌ها
اگر اعتبارسنجی اولیه ایمیل موفقیت‌آمیز باشد، داده‌های ایمیل به صف خروجی منتقل می‌شوند.
اگر اعتبارسنجی اولیه ایمیل ناموفق باشد، ایمیل در صف خطا قرار می‌گیرد.
5. Workerهای SMTP خروجی رویدادها را از صف خروجی می‌کِشند و اطمینان حاصل می‌کنند که ایمیل‌ها عاری از هرزنامه و ویروس هستند.
6. ایمیل خروجی در "پوشه ارسال شده" در لایه ذخیره‌سازی ذخیره می‌شود.
7. workerهای مربوط به SMTP خروجی ایمیل را به سرور ایمیل گیرنده ارسال می‌کنند. هر پیام در صف خروجی شامل تمام متادیتای مورد نیاز برای ایجاد یک ایمیل است. یک صف پیام توزیع شده یک جزء حیاتی است که پردازش ایمیل غیرهمگام را امکان‌پذیر می‌کند. با جدا کردن workerهای SMTP خروجی از وب سرورها، می‌توانیم workerهای SMTP خروجی را به طور مستقل مقیاس‌پذیر کنیم.
ما اندازه صف خروجی را از نزدیک نظارت می‌کنیم. اگر تعداد زیادی ایمیل در صف گیر کرده باشند، باید علت مشکل را تجزیه و تحلیل کنیم. درنتیجه احتمالات زیر وجود دارد:
سرور ایمیل گیرنده در دسترس نیست. در این صورت، باید ارسال ایمیل را در زمان دیگری دوباره امتحان کنیم. استراتژی عقب‌نشینی نمایی ممکن است یک استراتژی تلاش مجدد خوب باشد.
مصرف‌کننده‌های کافی برای ارسال ایمیل‌ها وجود ندارد. در این صورت، ممکن است نیاز به مصرف‌کننده‌های بیشتر برای کاهش زمان پردازش داشته باشیم.
