31 de julho de 2026
Plataforma de agendamento distribuído com microsserviços resilientes e observabilidade
Guilherme Silva de Andrade; Gabriel Custódio Rangel
DOI: 10.22167/2675-6528-202600873
Artigo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.
Resumo
A crescente adoção de arquiteturas baseadas em microsserviços intensificou a demanda por soluções que garantam alta disponibilidade, resiliência e observabilidade em ambientes distribuídos, pois falhas em serviços dependentes podem causar cascatas de indisponibilidade e dificultar a detecção e recuperação. Para resolver esse problema em sistemas distribuídos, desenvolveu-se uma plataforma de agendamento distribuído implementada em microsserviços, aplicando práticas consolidadas de resiliência, como circuit breaker e retry com backoff exponencial, e observabilidade integrada, incluindo tracing distribuído, métricas e dashboards. A solução foi implementada em .NET 10 com arquitetura limpa, padrão CQRS via MediatR e o pipeline de resiliência Polly, e validada por testes que simularam falhas reais. Os resultados empíricos demonstraram a efetividade da abordagem: o circuit breaker reduziu o tempo de falha de aproximadamente 1.350ms para 0,02ms por requisição, eliminando custos desnecessários e impedindo efeitos em cascata. O fluxo completo entre os três microsserviços foi validado, confirmando alta disponibilidade mesmo em cenários de falhas pontuais ou degradação de serviços. Concluiu-se que a combinação de padrões de resiliência e observabilidade resolveu efetivamente o problema de falhas em cascata, garantindo a continuidade operacional do sistema.
Palavras-chave: Alta disponibilidade; Arquitetura distribuída; Microsserviços; Observabilidade; Resiliência.
1. Introdução
A evolução das arquiteturas de software tem sido marcada por uma busca contínua por maior eficiência, escalabilidade e flexibilidade. Nesse cenário, as arquiteturas baseadas em microsserviços emergiram como um paradigma dominante para o desenvolvimento de sistemas distribuídos, oferecendo vantagens como a capacidade de desenvolver, implantar e escalar serviços de forma independente. Essa abordagem modular, onde cada serviço é autônomo e focado em uma funcionalidade específica, permite que equipes trabalhem de maneira mais ágil e que o sistema como um todo se adapte melhor às demandas crescentes. No entanto, a descentralização inerente a essa arquitetura, embora traga benefícios, também introduz uma camada significativa de complexidade e desafios operacionais.
Um dos desafios mais críticos em ambientes de microsserviços reside na gestão de falhas. Quando um serviço dependente falha, mesmo que temporariamente, essa falha pode se propagar rapidamente por todo o sistema, resultando em cascatas de indisponibilidade que afetam a experiência do usuário e comprometem a operação. A detecção e a recuperação de problemas tornam-se particularmente difíceis em sistemas distribuídos, onde as interações entre os componentes são complexas e o estado global do sistema é difícil de inferir a partir de um único ponto. Essa vulnerabilidade exige estratégias proativas para garantir a continuidade e a estabilidade.
Para mitigar esses riscos, a resiliência em sistemas distribuídos é um conceito fundamental, referindo-se à capacidade de um sistema de resistir a falhas e se recuperar delas sem que o usuário final seja impactado. Essa abordagem é sustentada por padrões de engenharia de software resiliente, como o “circuit breaker”, que impede que um serviço continue a chamar um serviço dependente que está falhando, e o “retry”, que permite que as requisições sejam automaticamente retentadas após uma falha transitória (Nygard, 2018). A implementação dessas políticas de resiliência é crucial para promover a tolerância a falhas e evitar a propagação de problemas, sendo a biblioteca Polly uma ferramenta amplamente utilizada no ecossistema .NET para aplicar esses padrões de forma eficaz.
Complementar à resiliência, a observabilidade é um pilar essencial para compreender o comportamento de sistemas distribuídos em tempo real. Ela não se limita a monitorar o estado atual, mas permite diagnosticar falhas, identificar gargalos de desempenho e rastrear o fluxo de execução através de múltiplos serviços (Hausenblas, 2022). Ferramentas como o tracing distribuído (por exemplo, Jaeger), a coleta de métricas (como Prometheus) e a visualização de dados em dashboards (como Grafana) fornecem a visibilidade operacional necessária para identificar rapidamente a causa raiz de problemas e garantir uma resolução eficiente. Juntas, resiliência e observabilidade formam uma estratégia robusta para gerenciar a complexidade e a imprevisibilidade dos ambientes distribuídos.
Nesse contexto, plataformas que dependem de orquestrações complexas, como sistemas de agendamento distribuído, são particularmente suscetíveis a falhas na comunicação entre serviços, sobrecarga de componentes e dificuldades no rastreamento de problemas operacionais. Portanto, a adoção de estratégias robustas de resiliência e observabilidade não é apenas uma boa prática, mas uma necessidade para garantir a disponibilidade, confiabilidade e escalabilidade de tais sistemas. Diante dessa problemática, este trabalho propôs a modelagem e implementação de uma plataforma de agendamento distribuído baseada em microsserviços, incorporando práticas consolidadas de resiliência e observabilidade, com o objetivo de avaliar o impacto dessas práticas na disponibilidade e no comportamento do sistema sob condições de falha.
2. Material e Métodos
A pesquisa caracterizou-se como um estudo de natureza aplicada, com abordagem metodológica focada no desenvolvimento e validação empírica de uma solução tecnológica. O objetivo principal foi resolver o problema de falhas em sistemas distribuídos, especificamente em um contexto de microsserviços. Para tanto, adotou-se uma estratégia de pesquisa que envolveu a modelagem, implementação e avaliação de uma plataforma de agendamento distribuído, incorporando práticas consolidadas de resiliência e observabilidade.
A estratégia de pesquisa foi estruturada em quatro etapas principais. Primeiramente, identificaram-se padrões de resiliência consolidados, como “retry” e “circuit breaker”. Em seguida, esses padrões foram implementados em uma plataforma real de microsserviços. A terceira etapa consistiu na instrumentação completa da observabilidade para monitorar e validar o comportamento do sistema. Por fim, executaram-se testes que simularam falhas reais, visando demonstrar a operacionalidade contínua do sistema sob condições adversas.
A definição dos domínios de negócio da plataforma foi realizada por meio da técnica de “Event Storming” (Brandolini, 2019). Essa abordagem colaborativa permitiu o mapeamento visual dos fluxos de eventos, comandos, entidades e processos, facilitando a identificação dos “Bounded Contexts” e das interações entre os microsserviços. Foram identificados três microsserviços principais: Chronos, Hermes e Iris, cada um com responsabilidades e mecanismos de comunicação específicos.
O microsserviço Chronos foi responsável pela gestão de agendamentos, utilizando comunicação REST HTTP síncrona e RabbitMQ assíncrona para saída. Hermes gerenciou usuários, com comunicação de entrada via REST HTTP e sem saída externa. Iris, o serviço de notificações, recebeu comunicação de entrada via RabbitMQ e registrou logs estruturados. Essa divisão de responsabilidades visou maximizar a coesão e reduzir o acoplamento entre os componentes do sistema.
A arquitetura da solução foi concebida com base no padrão de microsserviços, seguindo os princípios da Arquitetura Limpa (Martin, 2012, 2017) e os princípios SOLID. Essa abordagem garantiu a separação clara de responsabilidades, baixo acoplamento e alta coesão. Cada serviço foi organizado em camadas como Domain, Application, Infrastructure, Contracts, Api e um projeto transversal Core, promovendo uma estrutura modular e de fácil manutenção.
O padrão CQRS (Command Query Responsibility Segregation) foi implementado utilizando a biblioteca MediatR 12.4.1, separando as operações de escrita (Commands) das operações de leitura (Queries). A comunicação entre os serviços foi planejada de forma híbrida, empregando APIs REST para chamadas síncronas e RabbitMQ Client 7.2.1 LTS para troca de mensagens assíncronas. Essa combinação favoreceu a escalabilidade, resiliência e o baixo acoplamento (Dragoni et al., 2017).
A plataforma foi desenvolvida utilizando .NET 10 e ASP .NET Core para o
backend
dos microsserviços. Para persistência de dados, empregou-se PostgreSQL 15. A mensageria assíncrona foi gerenciada pelo RabbitMQ Client 7.2.1 LTS. A resiliência foi implementada com a biblioteca Polly (Microsoft.Extensions.Http.Resilience), especificamente para os padrões “retry” e “circuit breaker”.
As práticas de resiliência foram integradas desde o desenho arquitetural, utilizando a biblioteca Polly para aplicar os padrões de “retry” com
backoff
exponencial e “circuit breaker” (Nygard, 2018). O pipeline de resiliência foi configurado no serviço Chronos para a comunicação com o Hermes. Essa configuração incluiu três tentativas automáticas de “retry” e a abertura do circuito após 50% de falhas, considerando um mínimo de três requisições avaliadas, permanecendo aberto por 30 segundos.
A arquitetura incorporou uma camada de observabilidade em todos os três serviços para garantir visibilidade operacional e diagnóstico em tempo real. O “tracing” distribuído foi configurado com OpenTelemetry, instrumentando automaticamente as requisições HTTP e exportando os dados para o Jaeger via protocolo OTLP. A coleta de métricas foi realizada com prometheus-net, expondo o
endpoint
/metrics com contadores automáticos de requisições, latência e
status codes
(Hausenblas, 2022; Chen et al., 2021).
As métricas coletadas pelo prometheus-net foram consumidas pelo Prometheus e visualizadas em dashboards no Grafana. Essa infraestrutura de observabilidade viabilizou o monitoramento contínuo dos serviços, a análise de desempenho, a identificação de gargalos e a antecipação de possíveis falhas. A rastreabilidade do fluxo de execução através de múltiplos serviços foi garantida, permitindo a correlação de eventos e o diagnóstico preciso de problemas.
A infraestrutura de suporte para os testes foi provisionada localmente via Docker Compose, utilizando o repositório
gsa.iris-infra
. Incluíram-se
containers
para RabbitMQ, PostgreSQL, Jaeger, Prometheus e Grafana. Embora a orquestração em Kubernetes com infraestrutura em nuvem (Azure Container Apps) fosse prevista, a validação em ambiente local otimizou os ciclos de desenvolvimento e permitiu testes de resiliência com controle preciso de cenários de falha.
Os testes automatizados foram implementados com xUnit, NSubstitute e FluentAssertions, cobrindo as camadas de Domain, Application e Infrastructure do serviço Chronos. Testes unitários validaram o comportamento isolado de cada
handler
com
mocks
das dependências externas. Testes de integração validaram o comportamento do pipeline Polly com
handlers
HTTP controlados, garantindo a reprodutibilidade dos cenários de resiliência.
Os testes de resiliência foram conduzidos com o serviço Hermes intencionalmente indisponível para validar o comportamento do pipeline Polly. Adicionalmente, o fluxo completo da plataforma foi validado com os três serviços (Chronos, Hermes e Iris) rodando simultaneamente. Essa validação end-to-end confirmou a rastreabilidade do fluxo de ponta a ponta, utilizando um mesmo identificador de agendamento nos logs dos três serviços.
3. Resultados e Discussão
Os resultados obtidos neste estudo referem-se à implementação e validação de uma plataforma de agendamento distribuído, composta por três microsserviços, e à avaliação do impacto da aplicação de padrões de resiliência e observabilidade. A análise abrangeu o fluxo completo de comunicação síncrona e assíncrona entre os serviços, o comportamento do pipeline de resiliência Polly em cenários de falha e de sucesso, a validação por meio de testes automatizados e a eficácia da instrumentação de observabilidade com OpenTelemetry e Prometheus. Esses achados confirmam a hipótese central da pesquisa sobre a redução do impacto de falhas em sistemas distribuídos.
Fluxo end-to-end validado
A plataforma de agendamento foi implementada e validada com os três microsserviços — Chronos (gestão de agendamentos), Hermes (gestão de usuários) e Iris (notificações) — operando simultaneamente. Ao processar uma requisição de criação de agendamento (POST /api/agendamentos), o serviço Chronos iniciou a validação do usuário, realizando uma consulta síncrona via HTTP ao serviço Hermes. Essa consulta foi concluída com sucesso, recebendo uma resposta 200 em aproximadamente 242 milissegundos, demonstrando a comunicação eficaz entre os serviços em um cenário saudável.
Após a validação bem-sucedida do usuário, o serviço Chronos prosseguiu com a criação do agendamento e sua persistência no repositório de dados. Subsequentemente, publicou um evento `AgendamentoCriadoEvent` em um cluster RabbitMQ, utilizando o padrão Outbox para garantir a consistência. O serviço Iris, responsável pelas notificações, consumiu essa mensagem de forma assíncrona, deserializou o evento e processou a notificação, registrando o log correspondente. Esse fluxo demonstrou a capacidade do sistema de orquestrar operações complexas de forma distribuída.
A rastreabilidade do fluxo de ponta a ponta foi confirmada pela presença do mesmo identificador de agendamento nos logs dos três serviços envolvidos. Essa capacidade de rastreamento, viabilizada pela instrumentação com OpenTelemetry, é crucial para o diagnóstico em ambientes distribuídos, permitindo que os operadores compreendam o caminho de uma requisição através de múltiplos componentes. A observabilidade integrada, portanto, forneceu a visibilidade necessária para validar a correta execução das operações e identificar potenciais pontos de falha.
Durante a validação do fluxo completo, observou-se que o pipeline de resiliência Polly, configurado no serviço Chronos para a comunicação com o Hermes, registrou as tentativas bem-sucedidas com um resultado 200 e o status “Handled: False”. Esse comportamento indica que o mecanismo de proteção estava ativo, mas não impôs um overhead significativo quando o serviço dependente (Hermes) estava disponível e operando normalmente. Tal achado é fundamental, pois demonstra que as políticas de resiliência podem ser integradas sem comprometer o desempenho em condições ideais de operação.
Comportamento do pipeline de resiliência
Os testes de resiliência foram conduzidos em um ambiente controlado, simulando a indisponibilidade intencional do serviço Hermes para avaliar o comportamento do pipeline Polly. Foram realizadas cinco requisições consecutivas ao serviço Chronos, que tentava se comunicar com o Hermes. A primeira requisição demonstrou o funcionamento do padrão “retry” com backoff exponencial, executando três tentativas adicionais antes de esgotar o pipeline, com atrasos de aproximadamente 1,21 segundos, 3,58 segundos e 4,85 segundos entre as tentativas, totalizando cerca de 10 segundos para a conclusão da operação.
Durante essa sequência de falhas na primeira requisição, o “circuit breaker” atingiu o limiar configurado, que era de 50% de falhas com um mínimo de três requisições avaliadas, e abriu o circuito. Com o circuito em estado aberto, as quatro requisições subsequentes foram bloqueadas imediatamente, sem qualquer tentativa de conexão de rede. O tempo médio de resposta para essas requisições bloqueadas foi de aproximadamente 0,02 milissegundos, demonstrando a eficácia do “circuit breaker” em evitar chamadas desnecessárias a um serviço indisponível.
A comparação entre o tempo de falha sem resiliência e com o circuito aberto revela uma melhoria substancial. Sem a aplicação dos padrões de resiliência, uma única tentativa de conexão a um serviço indisponível levaria aproximadamente 1.350 milissegundos. Com o “circuit breaker” aberto, esse tempo foi reduzido para cerca de 0,02 milissegundos por requisição, representando uma melhoria de aproximadamente 99,99% no tempo de resposta em um cenário degradado. Essa redução é crítica em sistemas de alta concorrência, pois impede que falhas localizadas se propaguem e causem cascatas de indisponibilidade, protegendo a aplicação como um todo (Costa et al., 2022; Zhang et al., 2022).
A configuração do pipeline Polly no serviço Chronos estabeleceu um período de 30 segundos para o circuito permanecer aberto antes de tentar uma recuperação. Esse período foi validado durante os testes, confirmando que o sistema aguarda o tempo necessário para que o serviço dependente possa se restabelecer, evitando novas tentativas prematuras que poderiam sobrecarregar ainda mais o serviço em recuperação. Essa abordagem alinha-se às melhores práticas de resiliência em sistemas distribuídos, conforme descrito por Nygard (2018).
A decisão de não aplicar o padrão SAGA para orquestração de transações distribuídas, inicialmente considerada, foi baseada em uma análise arquitetural aprofundada. Verificou-se que o fluxo de agendamento (validação de usuário, criação e notificação) não envolvia transações compensáveis em múltiplos serviços que demandassem reversão. Assim, o “circuit breaker” com “retry” foi considerado a alternativa mais apropriada para lidar com falhas parciais em chamadas HTTP síncronas, enquanto o RabbitMQ assíncrono garantiu a entrega eventual da notificação, mesmo com falhas temporárias do consumidor. Essa escolha reflete uma maturidade arquitetural e uma decisão deliberada baseada nas características do domínio.
Validação por testes automatizados
Os testes automatizados foram cruciais para confirmar programaticamente o comportamento esperado dos componentes críticos da plataforma. Utilizando xUnit, NSubstitute e FluentAssertions, foram desenvolvidos conjuntos de testes que cobriram as camadas de Domain, Application e Infrastructure do serviço Chronos. Os testes unitários validaram o comportamento isolado de cada handler, empregando mocks para simular as dependências externas e garantir a especificidade da validação.
Os testes de integração, por sua vez, focaram na validação do comportamento do pipeline Polly, utilizando handlers HTTP controlados para simular cenários de sucesso e falha. Essa abordagem permitiu a reprodutibilidade dos cenários de resiliência, assegurando que o sistema reagiria conforme o esperado sob diferentes condições. A cobertura de testes incluiu cinco testes para `AgendamentoTests`, seis para `CriarAgendamentoHandlerTests`, três para `ObterAgendamentoHandlerTests`, três para `InMemoryAgendamentoRepositoryTests` e quatro para `HermesClientResilienceTests`, todos com resultados de aprovação.
Um teste específico, `ValidarUsuario_AposMultiplasFalhas_CircuitBreakerDeveAbrir`, confirmou que, após múltiplas falhas, o contador de chamadas HTTP ao servidor não aumentava. Isso demonstrou que o circuito aberto bloqueava efetivamente as requisições em nível de infraestrutura, impedindo o acesso desnecessário à rede e ao serviço indisponível. Adicionalmente, os testes do `CriarAgendamentoHandler` validaram que o publisher RabbitMQ era invocado exatamente uma vez após a criação bem-sucedida de um agendamento e que não era chamado quando o usuário era inválido, garantindo a integridade do fluxo de eventos e a consistência dos dados.
Observabilidade instrumentada
A arquitetura incorporou uma camada robusta de observabilidade em todos os três serviços, essencial para garantir visibilidade operacional e apoiar o diagnóstico de problemas em tempo real. O “tracing” distribuído foi configurado com OpenTelemetry, que instrumentou automaticamente as requisições HTTP e exportou os dados para o Jaeger via protocolo OTLP. Essa configuração permitiu a captura de traces detalhados para cada requisição processada, incluindo as chamadas HTTP ao Hermes e os eventos do pipeline Polly, fornecendo uma visão clara do fluxo de execução através dos microsserviços.
A coleta de métricas foi realizada com prometheus-net, expondo o endpoint `/metrics` em cada serviço com contadores automáticos de requisições, latência e status codes. Essas métricas foram consumidas pelo Prometheus e visualizadas em dashboards no Grafana. Essa infraestrutura de monitoramento contínuo viabilizou a análise de desempenho, a identificação de gargalos e a antecipação de possíveis falhas, confirmando a eficácia da abordagem descrita por Hausenblas (2022) e Chen et al. (2021) para sistemas distribuídos.
A infraestrutura de suporte para a validação foi provisionada via Docker Compose, incluindo os containers de RabbitMQ, PostgreSQL, Jaeger, Prometheus e Grafana. Embora o projeto inicial previsse orquestração em Kubernetes, a validação em ambiente local otimizou os ciclos de desenvolvimento e permitiu testes de resiliência com controle preciso de cenários de falha. A arquitetura implementada é agnóstica ao gerenciador de containers, sendo a configuração de rede, persistência e observabilidade declarativa e transferível para orquestração em Kubernetes, requerendo apenas a conversão dos arquivos docker-compose.yml para manifests YAML.
A separação de responsabilidades entre os três microsserviços, aliada ao desacoplamento proporcionado pelo RabbitMQ entre Chronos e Iris, demonstrou na prática os benefícios arquiteturais de sistemas distribuídos (Newman, 2015). A rastreabilidade do mesmo identificador de agendamento nos logs dos três serviços, conforme já mencionado, comprovou a eficácia da observabilidade para o diagnóstico de fluxos distribuídos, alinhando-se às discussões de Gomes et al. (2024) sobre a importância da visibilidade em ambientes complexos.
Em síntese, os resultados confirmaram que a aplicação combinada de padrões de resiliência, como “retry” com backoff exponencial e “circuit breaker”, e uma robusta camada de observabilidade, incluindo tracing distribuído e métricas, resolveu efetivamente o problema de falhas em cascata em sistemas distribuídos. A plataforma de agendamento demonstrou alta disponibilidade e capacidade de diagnóstico em tempo real, com o “circuit breaker” reduzindo o tempo de impacto de falhas de aproximadamente 1.350 milissegundos para 0,02 milissegundos por requisição, garantindo a continuidade operacional do sistema mesmo em cenários adversos.
4. Conclusão
Este trabalho propôs a modelagem e implementação de uma plataforma de agendamento distribuído baseada em microsserviços, incorporando práticas consolidadas de resiliência e observabilidade, com o objetivo de avaliar o impacto dessas práticas na disponibilidade e no comportamento do sistema sob condições de falha. Verificou-se que a plataforma, composta por três microsserviços, operou com sucesso, validando o fluxo completo de comunicação síncrona e assíncrona. Os achados demonstraram que a aplicação do pipeline de resiliência Polly, com padrões de circuit breaker e retry com backoff exponencial, reduziu significativamente o tempo de impacto de falhas. Observou-se que o tempo de falha por requisição foi drasticamente diminuído de aproximadamente 1.350 milissegundos para 0,02 milissegundos quando o circuito estava aberto, prevenindo efetivamente a propagação de falhas em cascata. A observabilidade integrada, por meio de tracing distribuído, métricas e dashboards, forneceu a visibilidade operacional necessária para o diagnóstico em tempo real e a validação do comportamento do sistema. A robustez da solução foi confirmada por testes automatizados, que validaram o comportamento esperado dos componentes críticos e do pipeline de resiliência. Conclui-se que a combinação estratégica de resiliência e observabilidade é uma abordagem eficaz para garantir a continuidade operacional e a alta disponibilidade em sistemas distribuídos, mesmo diante de condições adversas.
Como limitação do estudo, destaca-se que a validação da plataforma ocorreu em um ambiente local, utilizando dados mockados em memória para simular as dependências. Para trabalhos futuros, recomenda-se a validação da solução em um ambiente de nuvem, como Kubernetes em produção, com carga real e banco de dados persistente, a fim de simular condições operacionais mais próximas da realidade. Adicionalmente, sugere-se a realização de testes de carga com ferramentas como Locust ou k6 para avaliar o desempenho sob estresse. Propõe-se também a extensão dos padrões de resiliência implementados, incluindo mecanismos como bulkhead e fallback, para ampliar a proteção contra falhas em cascata e fortalecer ainda mais a robustez do sistema.
Referências Bibliográficas
Brandolini, A. 2019. Introducing EventStorming: An act of deliberate collective learning. Leanpub.
Chen, L.; Limoncelli, T.; Sigelman, B. 2021. State of the art in observability for microservices. IEEE Software 38(6): 45-52.
Costa, L.; Pereira, F.; Almeida, J. 2022. Resiliência em sistemas distribuídos. IEEE Latin America Transactions 20(5): 800-810.
Dragoni, N.; Giallorenzo, S.; Lafuente, A.L.; Mazzara, M.; Montesi, F.; Mustafin, R.; Safina, L. 2017. Microservices: Yesterday, today, and tomorrow. p. 195-216. In: Mazzara, M.; Meyer, B. Present and Ulterior Software Engineering. Springer, Cham, Suíça.
Gomes et al., 2024 [Referência completa não encontrada no documento original]
Hausenblas, M. 2022. Observability—A manifesto. Disponível em: <https://o11y.wiki/manifesto/>. Acesso em: 02 abr. 2025.
Martin, R.C. 2012. The clean architecture. The Clean Coder Blog. Disponível em: <https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html>. Acesso em: 02 abr. 2025.
Martin, R.C. 2017. Clean Architecture: A craftsman’s guide to software structure and design. Prentice Hall, Upper Saddle River, NJ, EUA.
Newman, S. 2015. Building Microservices: Designing fine-grained systems. O’Reilly Media, Sebastopol, CA, EUA.
Nygard, M.T. 2018. Release It!: Design and deploy production-ready software. 2ed. Pragmatic Bookshelf, Raleigh, NC, EUA.
Zhang, Y.; Wang, P.; Lin, H. 2022. Failure analysis in distributed systems. ACM Computing Surveys 54(7): 1-38.
Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq
Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy

