Os requisitos do aplicativo mudaram drasticamente nos últimos anos. Há apenas alguns anos, um grande aplicativo tinha dezenas de servidores, segundos de tempo de resposta, horas de manutenção offline e gigabytes de dados.
Hoje, os aplicativos são implantados em tudo, desde dispositivos móveis a clusters baseados em nuvem executando milhares de processadores multi-core. Os usuários esperam tempos de resposta em milissegundos e 100% de disponibilidade. Os dados são medidos em petabytes. As demandas de hoje simplesmente não são atendidas pelas arquiteturas de software de ontem.
Aplicações tradicionais
Cada solicitação está usando 2 processos em execução, um para cada instância do servidor HTTP e servidor de banco de dados. A estrutura PHP também pode gerar seu próprio processo adicional.
A instância do servidor HTTP está gerando um objeto de solicitação, que é principalmente sobrecarregado para uso posterior.
A instância do banco de dados está bloqueando a resposta até que tenha concluído sua tarefa.
A resposta do banco de dados está sendo armazenada em buffer pelo processo PHP para gerar o DTO (objeto de transferência de dados).
O processo PHP está usando o DTO para gerar uma resposta JSON para a instância do servidor HTTP.
Todo o processo, começando com a solicitação HTTP até servir a resposta de volta ao cliente, está sendo executado no mesmo thread. Isso usa o comportamento padrão da CPU, o que leva a um uso desequilibrado dos núcleos da CPU.
Aplicações reativas
Acreditamos que todos os aspectos necessários já são reconhecidos individualmente: queremos sistemas que sejam responsivos, resilientes, elásticos e orientados por mensagens. Chamamos isso de Sistemas Reativos. 
Não há necessidade de um servidor HTTP. O aplicativo está usando um único processo. PHP e o banco de dados (SQLite) estão rodando dentro deste processo.
Não há necessidade de um objeto de solicitação HTTP sobrecarregado. Os dados necessários são limitados principalmente ao método de solicitação, caminho e carga útil.
A resposta pode ser enviada imediatamente ao cliente, enquanto os dados são processados em background e todas as etapas necessárias são tratadas de forma assíncrona, por meio de eventos.
O banco de dados não está bloqueando a resposta, pois sua tarefa está sendo tratada de forma assíncrona.
Todo o processo está acontecendo em um soquete TCP persistente, permitindo que a resposta seja transmitida ao cliente.
O processo está gerenciando suas tarefas com vários threads, equilibrando o uso de todos os núcleos da CPU.
Exemplo de implementação
Como exemplo de implementação, usamos componentes leves que empacotamos em contêineres do Docker. AlpineOS e Ubuntu já vêm como imagens Docker prontas para serem usadas.
ReactPHP é responsável por estabelecer o soquete TCP, transferir a solicitação HTTP bruta e enviar a resposta HTTP de volta.
A microestrutura PIMF é responsável por gerenciar os recursos HTTP usando os métodos de solicitação HTTP, validar os dados e manipular a interação de persistência. 
Você pode encontrar o código-fonte no GitHub: https://github.com/gjerokrsteski/reactphp-pimf
Sinta-se à vontade para fazer um fork e experimente você mesmo!
Conclusão
Os sistemas construídos como Reactive Systems são mais flexíveis, fracamente acoplados e escaláveis. Isso os torna mais fáceis de desenvolver e passíveis de mudança. Eles são significativamente mais tolerantes ao fracasso e, quando ocorre, eles o enfrentam com elegância, em vez de desastre. Os sistemas reativos são altamente responsivos, fornecendo aos usuários um feedback interativo eficaz.
Recursos:
The Reactive Manifesto
http://www.reactivemanifesto.org
O que é programação reativa?
https://medium.com/reactive-programming/what-is-reactive-programming-bc9fa7f4a7fc#.j5m4cnvck
ReactPHP
http://reactphp.org
PIMF
http://pimf-framework.de
Docker
https: //docs.docker .com