Al igual que muchas preguntas de arquitectura de "panorama general", la mejor solución es realmente una de esas ... depende. ¿Puede controlar el entorno de implementación? Es decir... ¿puede utilizar cualquier servidor de correo electrónico que desee o está obligado a utilizar uno que ya está instalado y alojado? ¿Puede ejecutar código en la misma máquina que el servicio SMTP? Estas preguntas, y muchas otras, deben considerarse para llegar a una arquitectura (casi) óptima.
Dado eso, voy a hacer un par de suposiciones y ofrecer algunas ideas que creo que vale la pena explorar...
Debería buscar un sistema de mensajería de alto rendimiento. Específicamente, eche un vistazo a RabbitMQ . RabbitMQ es confiable y eficiente, y la distribución de la carga de trabajo basada en eventos entrantes asincrónicos es un patrón que discuten específicamente en sus (en mi opinión, muy buenos) tutoriales.
Con un servidor de mensajería como este, tiene un proceso que recibe el correo electrónico entrante. Preferiblemente, esto se hace como parte del proceso SMTP, o al menos muy cerca de él, especialmente con la carga de trabajo que ha mencionado. Si no tiene otra opción, entonces sus ideas sobre el uso de cron para recopilar mensajes a través de POP o IMAP tendrán que funcionar, por ahora.
El proceso de recopilación de correo electrónico enviaría mensajes a la cola de RabbitMQ. (Quizás no literalmente los correos electrónicos en sí, aunque esa es una posibilidad, pero estaba pensando más en referencias a dónde se almacena el correo electrónico de manera eficiente). A continuación, ejecuta varios procesos de trabajo que están suscritos a una cola de mensajes con nombre. RabbitMQ (o cualquier servicio de mensajería que elija) luego distribuiría esos mensajes en forma rotativa a los suscriptores individuales. Si ya están cargados, los procesos de trabajo pueden NACKear el mensaje o enviar su propio mensaje de flujo de control al servicio. Con una carga de trabajo MUY alta (nuevamente, como usted ha propuesto), recomiendo encarecidamente algún tipo de proceso de administración que controle el estado general del sistema distribuido. El gerente reuniría estadísticas de tiempo de ejecución (MUY útiles para la planificación, optimización y refactorización del sistema general en el futuro) y tendría la capacidad de poner en marcha y cerrar nuevos procesos de trabajo. Antes de llegar a esa carga de trabajo tan alta, y suponiendo que sus procesos de trabajo son estables y pueden vivir mucho tiempo sin fragmentación de la memoria, etc., entonces bastará con usar el servidor de mensajes para distribuir el trabajo.
Si sirve de algo, tengo algo de experiencia escribiendo procesadores de correo electrónico (específicamente xmail - uno que recomendaría si recién está comenzando su proyecto y tiene mucho control sobre sus primeras etapas). Además, actualmente estoy usando RabbitMQ para crear un sistema de almacenamiento en caché de resultados de múltiples agentes para una red informática científica importante.
De todos modos... ¡buena suerte con tu proyecto!
