Guilherme Biff Zarelli gbzarelli

Entendendo a Escala Horizontal em Bancos NoSQL

“Partitioning data is essential when scaling systems to handle large amounts of data and traffic.” — Martin Fowler

Aplicações modernas como redes sociais, e-commerces e serviços de streaming geram grandes volumes de dados rapidamente. Escalar verticalmente o banco pode não ser suficiente. A escalabilidade horizontal, que distribui os dados entre vários servidores, é uma solução comum em bancos NoSQL. Este artigo explica como isso funciona, com foco no MongoDB.

Conceito de Escalabilidade

Comparação dos Principais Garbage Collectors da JVM

Garbage Collector	Compactação e Fragmentação	STW (Stop-The-World)	Uso recomendado	Estrutura da Heap	Processos do GC	Trade-offs	Recursos Recomendados	Outros detalhes
Serial GC	✅ Compacta após Major GC ❌ Pode sofrer fragmentação antes da compactação	🔴 Alto (pausa total na coleta).	Aplicações pequenas com pouca alocação de memória.	Young Gen (Eden + Survivor) + Old Gen	Mark → Sweep → Compact	✅ Baixo consumo de memória ❌ STW muito longo	🔹 1 CPU Core 🔹 ≤ 1GB RAM	Usa uma única thread, causando longas pausas.
Parallel GC	✅ Compacta após Major GC ou Full GC ❌ Pode sofrer fragmentação antes da compactação	🔴 Alto (mas usa múlt

Configuração de Limit de CPU	Vantagens	Desvantagens	Quando Usar
Sem Limit de CPU	Permite que a JVM utilize todos os recursos disponíveis do nó, melhorando o desempenho e reduzindo contenção de CPU.	Pode causar concorrência com outras cargas de trabalho no cluster, levando a variações imprevisíveis de desempenho.	Recomendado para aplicações que requerem máximo desempenho e não competem por CPU com outras workloads.
Limit de CPU Definido	Garante que a aplicação não utilize mais CPU do que o estipulado, proporcionando maior previsibilidade e controle.	Pode causar throttling e reduzir a eficiência da JVM, especialmente para workloads de alto desempenho.	Útil para clusters compartilhados onde a CPU precisa ser alocada de forma controlada entre diferentes aplicações.

Escolha do Banco de Dados para o Serviço de Catálogo

Data: 07/01/2025
Status: Aprovado

Contexto:

Precisamos de um banco de dados para armazenar informações de produtos, incluindo descrições, preços e categorias. O sistema deve suportar um alto volume de consultas e permitir buscas eficientes.

Decisão:

(artigo recuperado do helpdev.com.br - criado em 08/2019)

Esse post vou abordar como realizar a instalação e configurações basicas do GitLab - CE , também como criar os executores de CI/CD para seu ambiente e mostrarei um caso prático de execução de uma pipeline . Não entrarei em detalhes sobre todas as coisas, pois a intenção é de uma documentação simples dos processos de instalação dessa ferramenta incrível;

É necessário para a execução do processo como um todo um ambiente linux com o Docker e docker-compose préviamente instalado, não vou abordar como realizar esses procedimentos nesse tutorial.

A instalação do Gitlab - CE é relativamente simples quando utilizamos o Docker, a seguir segue o compose já com algumas configurações de mapeamento de volumes e configuração de endereços, note que o IP representado no arquivo é da maquina local que estou realizando a configuração, caso tenha um domínio próprio basta subistituir, caso não tenha insira seu IP local.

Distribuição de eventos com Kafka e Webhook

(o projeto: https://github.com/gbzarelli/events-distribution-platform)

O projeto events-distribution-platform tem como intuito validar uma arquitetura que seja capaz de distribuir eventos utilizando o Kafka como plataforma de Streamming e notificar clientes via Webhooks.

Os webhooks serão cadastrados em uma base NoSQL baseado em filtros de tipo de eventos, assim cada usuário (associado a uma organização) poderia ter diferentes tipos de filtros para notificar diferentes endereços.

	apiVersion: networking.k8s.io/v1
	kind: Ingress
	metadata:
	name: ingress-my-services
	namespace: my-services
	annotations:
	alb.ingress.kubernetes.io/actions.ssl-redirect: >
	{"Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}}
	alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-east-1:xxxx:xxxxx
	alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'

	// Definição dos pinos
	const int gasSensorPin = A3; // Pino analógico do sensor MQ-2
	const int buzzerPin = 8; // Pino digital para o buzzer

	// Definição do valor limite para acionar o buzzer (ajuste conforme necessário)
	const int gasThreshold = 100;
	const int maxGasLevel = 1023; // Valor máximo que o sensor pode ler (10 bits)

	// Frequência mínima e máxima para o buzzer
	const int minFrequency = 100; // Frequência mínima do buzzer em Hz

	@AllArgsConstructor
	public class ReshippingOrderUseCase {

	private final OrderRepository orderRepository;
	private final CustomerRepository customerRepository;
	private final OrderRepository orderRepository;

	private final ShippingProviderClient shippingProviderClient;
	private final LogisticClient logisticsClient;