Minha verdadeira pergunta é:a pilha de tecnologia acima pode escalar 1.000.000 de mensagens por segundo (texto, imagens, vídeos)?
Claro que pode. Com o design certo e hardware suficiente. A pergunta que seu cliente deve fazer não é realmente se pode ser tão grande, mas a que custo e praticidade isso pode ser feito e essas são as melhores escolhas.
Vejamos cada peça que você mencionou:
node.js - Para um aplicativo centrado em E/S, é uma excelente opção para alta escala e pode escalar implantando muitas CPUs em um cluster (multiprocesso por servidor e multiservidor). A praticidade desse tipo de escala depende muito de que tipo de dados compartilhados todos esses processos de servidor precisam acessar. Normalmente, o armazenamento de dados acaba sendo o gargalo mais difícil no dimensionamento porque é fácil lançar mais servidores no processamento da solicitação. Não é tão fácil lançar mais hardware em um armazenamento de dados centralizado. Existem maneiras de fazer isso, mas depende muito das demandas do aplicativo de como você faz isso e de quão difícil é.
socket.io - Se você precisa de envio eficiente de mensagens pequenas no servidor, então o socket.io é provavelmente o melhor caminho a seguir, porque é o mais eficiente no envio ao cliente. Não é grande em todos os tipos de transporte embora. Por exemplo, eu não estaria movendo imagens ou vídeos grandes pelo socket.io, pois existem maneiras mais específicas de fazer isso. Portanto, o uso do socket.io depende muito do que exatamente o aplicativo deseja usá-lo. Se você quisesse enviar um vídeo para um cliente, também poderia enviar apenas um URL e fazer com que o cliente se virasse e solicitasse o vídeo por meio de um URL http normal usando uma tecnologia de alta escala bem conhecida.
Redis - Mais uma vez, ótimo para algumas coisas, não ótimo em tudo. Então, isso realmente depende do que você está tentando fazer. O que expliquei anteriormente é que o design de seu armazenamento de dados e o número de transações por meio dele provavelmente é onde estão seus problemas reais de escala. Se eu estivesse iniciando este trabalho, começaria com um entendimento das necessidades de armazenamento de dados para um servidor, transações por segundo de vários tipos, estratégia de cache, redundância, failover, persistência de dados, etc... dimensionar o acesso aos dados primeiro. Eu não teria certeza de que o redis era a escolha preferida. Eu provavelmente sugeriria que você precisa de um cara de banco de dados de alta escala como consultor no início do projeto.
Nginx - Muitos sites de alta escala usando nginx, então é certamente uma boa ferramenta. Se é exatamente a ferramenta certa para você depende do seu design. Eu provavelmente trabalharia nessa parte por último porque parece menos central para o design e, uma vez que o resto do sistema esteja definido, você pode considerar o que precisa aqui.
Amazon EC2 - Uma das várias opções possíveis. Essas escolhas são difíceis de comparar diretamente em uma comparação de maçãs com maçãs. Sistemas de grande escala foram construídos a partir do EC2, então há uma prova de conceito e a arquitetura geral parece ser uma combinação apropriada. Se você quisesse saber onde estão os verdadeiros gremlins, precisaria de um consultor que tivesse feito coisas de alta escala no EC2.
Amazon S3 - Eu pessoalmente conheço alguns sites de armazenamento e largura de banda muito altos usando S3 para vídeo e imagens. Funciona para isso.
Então ... essas são geralmente boas ferramentas para usar se forem usadas da maneira correta. Redis seria um ponto de interrogação dependendo das necessidades de armazenamento do aplicativo real (você forneceu zero requisitos e um banco de dados não pode ser selecionado com zero requisitos). Uma resposta mais fundamentada seria baseada em reunir um conjunto de requisitos de alto nível que analisam o que o sistema precisa ser capaz de fazer para atender a 1.000.000 de qualquer coisa. Esses requisitos podem ser comparados com os recursos conhecidos de algumas dessas peças para iniciar uma estimativa de dimensionamento de um sistema. Então, você teria que montar alguns testes de benchmarking para executar alguns testes em certas partes do sistema. Grande parte do sucesso do fracasso dependeria de como o aplicativo foi construído e de como as ferramentas foram usadas, bem como de quais ferramentas foram selecionadas. Você provavelmente pode fazer uma escala bem-sucedida com muitos tipos diferentes de ferramentas. Caramba, o Facebook é executado em PHP (bem, um PHP altamente modificado e personalizado que não é realmente PHP típico em tempo de execução).
