Mapeamento de Downtime da pagar.me

gistfile1.txt

# Mapeamento de Downtime da pagar.me

## Motivação

Trocando idéias com um desenvolvedor da pluralsight, absorvi bastante pensamentos no qual eles estavam tocando como eles gerem seus microserviços.
As premissas deles além de seguir bem a arquitetura de microserviços, eles tem mapeado os seguintes pontos:

* todo microserviço tem seu downtime mapeado com o tempo de downtime tolerável sem afetar os clientes.

* todo microserviço tem seu "cache" de messageria de suas dependencias (outros serviços que ele depende para leitura), com TTL (time to live) dentro da tolerância do tempo médio que o dado pode ser considerado "antigo" para ser usado pela frequencia média de sua alteração.. exemplificando, faço uma pergunta: temos que ler do banco de dados toda vez a configuração do cliente ou podemos ler somente uma vez a cada 3 dias e deixar cacheado ? podemos virar a chave para o cache se o serviço está com nível alarmante ou com algum alerta de nível médio e deixar o pessoal de Heartbeat arrumar até normalizar?

* todos os caches são guardados em um barramento de messageria (não sei informar a tecnologia), assim se novos serviços dispuserem das mesmas dependencias, basta plugar no barramento e documentar a nova dependencia.

Seguindo a premissa acima, provoco todos a começarmos a fazer o nosso dever de casa... conhecer nossos microserviços e como eles se interligam.

Claro que iremos mapear nossos serviço antigos, e assim teremos todo um mapa de risco entre os serviços.

## Serviços mapeados

Peço uma ajuda muito forte nessa parte, essa lista vai ajudar demais todos os pagarmers, e principalmente as equipes que lidam com as horizontais (segurança e infraestrutura) a mitigar tudo que envolve nosso negócio. E podemos inclusive transformar em uma base de conhecimento que cada serviço novo tem que estar documentado na nossa base de conhecimento antes mesmo de ir para produção.

Os serviços que temos são:

- pci stack
	* [ ] autobahn
	* [ ] thunderbolt
	* [ ] api-router

## Questionamentos que devemos fazer em cada microserviço

* O serviço pode ter downtime e não afetar o cliente?
* Quais são minhas dependencias de serviços da AWS?
* Quais são minhas dependencias de serviços de terceiros além da AWS?
* Se pode ter downtime, quanto tempo pode ficar fora sem que afete o cliente de fato?
* Como os serviços dependentes dele podem melhorar a tolerancia de tempo de downtime?
* De quem dependo? como posso tolerar dos meus dependentes? (primeiro nos outros microserviços, depois nos serviços da aws e terceiros)

---

Para escalabilidade:

* Quem são meus gargalos para que eu escale livremente de forma automática?
* Se a pagar.me triplicar de tamanho, aonde eu devo me preocupar?

---

Overkill na escalabilidade e tolerância

* O serviço está preparado para um cenário de sharding de dados?
* O serviço está preparado para um cenário multi-cloud / multi-region?

## Conclusão

Com essa lista podemos trazer uma maturidade maravilhosa que é nosso autoconhecimento do quanto podemos tolerar.