IX. Descartabilidade
Maximize robustez com inicialização rápida e desligamento gracioso
Os processos de um app doze-fatores são descartáveis, significando que podem ser iniciados ou parados a qualquer momento. Isso facilita o escalonamento elástico, rápido deploy de código ou mudanças de configuração, e robustez de deploys de produção.
Processos devem empenhar-se em minimizar o tempo de inicialização. Idealmente, um processo leva alguns segundos do tempo que o comando de inicialização é executado até o ponto que ele estará pronto para receber requisições ou tarefas. Períodos curtos de inicialização provém mais agilidade para o processo de release e de escalonamento; e ele adiciona robustez, pois o gestor de processos pode mais facilmente mover processos para outras máquinas físicas quando necessário.
Processos desligam-se graciosamente quando recebem um sinal SIGTERM do seu gestor de processos. Para um processo web, desligamento gracioso é alcançado quando cessa de escutar à porta de serviço (consequentemente recusando quaisquer requisições novas), permitindo qualquer requisição em andamento terminar, e então desligando. Implícito neste modelo é que as requisições HTTP são curtas (não mais que alguns poucos segundos), ou no caso de um longo polling, o cliente deve ser capaz de transparentemente tentar se reconectar quando a conexão for perdida.
Para um processo de trabalho (worker), desligamento gracioso é alcançado retornando a tarefa atual para fila de trabalho. Por exemplo, no RabbitMQ o trabalhador pode enviar um NACK; no Beanstalkd, a tarefa é retornada para a fila automaticamente sempre que um trabalhador se desconecta. Sistemas baseados em trava como o Delayed Job precisam se certificar de soltar a trava no registro da tarefa. Implícito neste modelo é que todas as tarefas são reentrantes, o que tipicamente é atingindo envolvendo os resultados numa transação, ou tornando a operação idempotente.
Processos também devem ser robustos contra morte súbida, no caso de uma falha de hardware. Ao passo que isso é muito menos comum que um desligamento via SIGTERM, isso ainda pode acontecer. Uma abordagem recomendada é usar um backend de filas robusto, como o Beanstalkd, que retorna tarefas à fila quando clientes desconectam ou esgotam o tempo de resposta. De qualquer forma, um app doze-fatores é arquitetado para lidar com terminações não esperadas e não graciosas. Crash-only design leva este conceito à sua conclusão lógica.