Skip to main content

Microsserviço 3

· 3 min read
Leandro Andrade
Leandro Andrade
Software Developer

Os microsserviços não são o fim, são o meio. A decisão de usá-los deve ser consciente e racional. Considere os microsserviços apenas se a arquitetura atual não puder evoluir ou apresentar limitações. Pense primeiro no simples: o que pode ser feito com o que temos atualmente antes de considerar a adoção dos microsserviços?

Microsserviço 2

· 5 min read
Leandro Andrade
Leandro Andrade
Software Developer

Definir uma boa fronteira em um microsserviço é extremamente importante já que ter a capacidade de alterá-lo isoladamente é essencial. Basicamente, os microsserviços são apenas outra forma de decomposição modular.

Microsserviço 1

· 10 min read
Leandro Andrade
Leandro Andrade
Software Developer

Microsserviços são serviços que podem ser lançados de forma independente e são modelados com base e um domínio de negócio.

Container status com CTOP

· One min read
Leandro Andrade
Leandro Andrade
Software Developer

Na utilização de containers, por exemplo em um teste de carga, podemos ter a necessidade de verificar o status do container, o quanto de recurso está sendo usado, seja cpu, seja memória.

Modelo de Design Docs

· 5 min read
Leandro Andrade
Leandro Andrade
Software Developer

Documento elaborado pelo time antes da codificação, de um projeto ou funcionalidade. A proposta é apresentar uma visão de alto nível com ênfase nos trade-offs considerados durante a decisão.

Tempo de respostas em SQL

· One min read
Leandro Andrade
Leandro Andrade
Software Developer

No artigo "Tempos de Resposta: Os 3 Limites Importantes" publicado em 1993, Jakob Nielsen, existe a regra "0,1 / 1 / 10" para construir interfaces bem performáticas:

  • 100ms: reação instantânea, significando que nenhum feedback especial é necessário exceto para exibir o resultado.
  • 1s: limite para o fluxo de pensamento do usuário permanecer ininterrupto, mesmo que o usuário perceba o atraso. O usuário perde a sensação de instantâneo.
  • 10s: limite para manter a atenção do usuário focada no diálogo. O usuário vai querer fazer outra coisa enquanto aguarda o computador finalizar.

Queremos que eventos dos nossos servidores respondam em menos de 100ms.

Para aplicações web e mobile, temos o termo SRT(server response time).

Para o page speed do google, SRT abaixo de 200ms é considerado bom tempo de resposta. Já cima de 1s, muito lento.

Desta forma, considerando que uma requisição HTTP pode realizar diversas operações em banco de dados, poderíamos criar a seguinte expectativa sobre as SQLs executas pelas aplicações:

  • > 10ms: bom desempenho
  • > 10ms e < 100ms: precisa ser otimizado.
  • > 100ms: desempenho baixo, precisa ser otimizado.

Referência