Como muitas questões de arquitetura "grandes", a melhor solução é realmente uma dessas... depende. Você pode controlar o ambiente de implantação? Ou seja... você pode usar qualquer servidor de e-mail que desejar ou está limitado a usar um que já esteja instalado e hospedado? Você pode executar o código na mesma máquina que o serviço SMTP? Essas perguntas e muitas outras devem ser consideradas para criar uma arquitetura (quase) ideal.

Dado isso, vou fazer algumas suposições e oferecer algumas ideias que acho que valem a pena explorar...

Você deve procurar um sistema de mensagens de alto desempenho. Especificamente, dê uma olhada em RabbitMQ . O RabbitMQ é confiável e eficiente, e a distribuição de carga de trabalho com base em eventos de entrada assíncronos é um padrão que eles discutem especificamente em seus tutoriais (na minha opinião, muito bons).

Com um servidor de mensagens como este, você tem um processo que recebe o e-mail de entrada. De preferência, isso é feito como parte do processo SMTP, ou pelo menos muito próximo a ele - especialmente com a carga de trabalho que você mencionou. Se você não tiver outra escolha, suas ideias sobre usar o cron para coletar mensagens via POP ou IMAP terão que funcionar, por enquanto.

O processo de coleta de e-mail então enviaria mensagens para a fila do RabbitMQ. (Talvez não literalmente os próprios e-mails, embora isso seja uma possibilidade, mas eu estava pensando mais como referências de onde o e-mail é armazenado com eficiência). Em seguida, você executa vários processos de trabalho que estão inscritos em uma fila de mensagens nomeada. O RabbitMQ (ou qualquer serviço de mensagens que você decidir) distribuirá essas mensagens de forma round-robin para os assinantes individuais. Se já carregados, os processos do trabalhador podem realizar o NACK da mensagem ou enviar sua própria mensagem de fluxo de controle de volta ao serviço. Com uma carga de trabalho MUITO alta (novamente, como você propôs), eu recomendo algum tipo de processo de gerenciamento que mantenha o controle da integridade geral do sistema distribuído. O gerente reuniria estatísticas de tempo de execução (MUITO útil para planejamento de crescimento futuro, otimização e refatoração do sistema geral) e teria a capacidade de ativar e encerrar novos processos de trabalho. Antes de chegar a essa carga de trabalho muito alta, e supondo que seus processos de trabalho sejam estáveis ​​e possam viver muito tempo sem fragmentação de memória, etc., apenas usar o servidor de mensagens para distribuir o trabalho deve ser suficiente.

Se vale a pena, tenho alguma experiência em escrever processadores de e-mail (especificamente xmail - um que eu recomendaria se você está apenas começando seu projeto e tem muito controle sobre seus estágios iniciais). Além disso, atualmente estou usando o RabbitMQ para construir um sistema de cache de resultados multiagente para uma grande grade de computação científica.

Enfim... boa sorte com seu projeto!