<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Comentários sobre: Observabilidade	</title>
	<atom:link href="https://ramondomingos.com.br/observabilidade/feed/" rel="self" type="application/rss+xml" />
	<link>https://ramondomingos.com.br/observabilidade/</link>
	<description>Conteúdo sobre tecnologia e engenharia de software.</description>
	<lastBuildDate>Mon, 21 Aug 2023 00:06:05 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.0.4</generator>
	<item>
		<title>
		Por: Os desafios de desenvolver um software escalável - Ramon Domingos Blog		</title>
		<link>https://ramondomingos.com.br/observabilidade/#comment-4</link>

		<dc:creator><![CDATA[Os desafios de desenvolver um software escalável - Ramon Domingos Blog]]></dc:creator>
		<pubDate>Sun, 20 Aug 2023 23:56:11 +0000</pubDate>
		<guid isPermaLink="false">https://ramondomingos.com.br/?p=14#comment-4</guid>

					<description><![CDATA[[&#8230;] &#8211; Entenda onde existem gargalos: Entenda sua demanda, e veja onde existe locais que a requisição demora, quais os motivos. Query ? Limite do banco de dados? Complexidade do código? Escalar código ineficiente, não é uma prática aconselhada.&#8211; Paralelizar processamentos : Encontre processos que podem ser executados de forma paralela, sem impactos ao negócio. Promova uma arquitetura que consiga realizar esse processamento. Use mensagerias (rabbitmq, kafka, sqs..) para ter mais poder nessa etapa.&#8211; Trate erros: Os erros não devem se espalhar, nem impedir a continuidade dos outros processamentos. As mensagerias também apoiam nesse ponto, filas DLQ guardam mensagens com erros, para serem processadas depois.Tentativas: Não é porque não processou uma vez que a mensagem nunca irá processar, pode existir uma falha no outro serviço que você esta usando, utilize de técnicas para permitir o retry.&#8211; Monitoramento: Nunca é demais ter logos, métricas e tracing numa aplicação. Identifique como metrificar da melhor forma a saúde e os limites para escale-up/down da sua aplicação. Adicione alarmes para você ser avisado de qualquer instabilidade. ( tem post falando disso aqui) [&#8230;]]]></description>
			<content:encoded><![CDATA[<p>[&#8230;] &#8211; Entenda onde existem gargalos: Entenda sua demanda, e veja onde existe locais que a requisição demora, quais os motivos. Query ? Limite do banco de dados? Complexidade do código? Escalar código ineficiente, não é uma prática aconselhada.&#8211; Paralelizar processamentos : Encontre processos que podem ser executados de forma paralela, sem impactos ao negócio. Promova uma arquitetura que consiga realizar esse processamento. Use mensagerias (rabbitmq, kafka, sqs..) para ter mais poder nessa etapa.&#8211; Trate erros: Os erros não devem se espalhar, nem impedir a continuidade dos outros processamentos. As mensagerias também apoiam nesse ponto, filas DLQ guardam mensagens com erros, para serem processadas depois.Tentativas: Não é porque não processou uma vez que a mensagem nunca irá processar, pode existir uma falha no outro serviço que você esta usando, utilize de técnicas para permitir o retry.&#8211; Monitoramento: Nunca é demais ter logos, métricas e tracing numa aplicação. Identifique como metrificar da melhor forma a saúde e os limites para escale-up/down da sua aplicação. Adicione alarmes para você ser avisado de qualquer instabilidade. ( tem post falando disso aqui) [&#8230;]</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
