---
title: "Criando confiabilidade de app: a chave para o sucesso no web3"
description: "A confiabilidade do node é essencial para seu app web3. Descubra como a infraestrutura da Alchemy garante confiabilidade à medida que você escala."
---

# Criando confiabilidade de app: a chave para o sucesso no web3

Muitas equipes têm apps web3 fadados ao fracasso.

Por quê?

Porque os apps dependem totalmente de nodes, e nodes são extremamente difíceis de manter. Alguns motivos:

1. A confiabilidade dos nodes não pode ser construída em um vácuo; ela precisa vir acompanhada de escalabilidade e precisão dos dados
1. Nodes não são projetados para ser soluções de produção em larga escala
1. Espera-se que os nodes façam coisas demais
1. Nodes exigem manutenção em tempo integral
1. A eficácia dos nodes depende de navegar com sucesso por upgrades de rede ou hard forks de tempo imprevisível

Essas complicações tornam os nodes difíceis de gerenciar e manter.

Mas há duas dimensões arquiteturais que melhoram significativamente a confiabilidade dos nodes, **ou seja, a capacidade de um usuário interagir com seu app com sucesso quando precisar**:

- **Heterogeneidade**: sistemas diversos e complementares que conseguem lidar com requisições diferentes
- **Redundância**: sistemas de backup, de modo que, se um sistema cair, outros continuem no ar

No web3, a falta de confiabilidade pode ter consequências prejudiciais.

Veja o caso de um [marketplace de NFT](https://www.alchemy.com/dapps/best/nft-marketplaces) conhecido usando infraestrutura pouco confiável...

A plataforma deles era instável, o que gerava:

- Alta carga de engenharia
- UX degradada
- Mais de 190 horas de indisponibilidade em um único trimestre

Qual foi o impacto? **$6M em receita perdida.**

Não deixe isso acontecer com você.

**Neste artigo, vamos explicar:**

1. Por que manter a confiabilidade dos nodes é desafiador
1. Padrões comuns de infraestrutura de nodes e por que eles falham
1. Como a Alchemy trata os desafios de confiabilidade e constrói para confiabilidade em escala

## Por que manter a confiabilidade dos nodes é desafiador

Há **cinco** motivos principais pelos quais a confiabilidade é particularmente difícil de manter no web3:

### \(1\) A confiabilidade dos nodes não pode ser construída em um vácuo; ela precisa vir acompanhada de escalabilidade e precisão dos dados
Para criar um app altamente funcional, você precisa de confiabilidade, combinada com escalabilidade e precisão dos dados.

- **Escalabilidade**: a capacidade de continuar interagindo com a blockchain à medida que o tráfego do seu app **escala** 10x, 100x, 1000x ou mais.
- **Precisão dos dados**: o estado em que seu app retorna dados corretos e consistentes para cada usuário.

### **\(2\) nodes não são projetados para ser soluções de produção em larga escala**‍

Os nodes foram inicialmente projetados para ser executados por indivíduos, em casos de uso pessoais e de pequena escala. Embora sejam caros \($1000 / mês\), para esse caso de uso limitado, conseguem gerar confiabilidade suficiente e manter:

- **Escalabilidade**; o volume de requisições é controlado de forma previsível, limitando os riscos relacionados à escalabilidade necessária
- **Precisão dos dados**; como há apenas um node, [não há espaço para inconsistências de dados entre nodes](https://alchemy.com/blog/data-accuracy)

No entanto, um ambiente de desenvolvimento não é um ambiente de produção, e produção exige ferramentas muito diferentes.

<ExternalVideo
  url="https://vimeo.com/775874944"
  provider="vimeo"
  providerUid="775874944"
/>

### \(3\)** **espera-se que os nodes façam coisas demais
Espera-se que os nodes façam um número ilimitado de coisas, por exemplo, executar software peer-to-peer, funcionar como um banco de dados escalável, executar código arbitrário, etc.

Os nodes também não têm nenhuma "opinião" sobre o que devem ou não fazer.

Juntos, esses fatores têm duas ramificações principais:

- **Escalabilidade**; conforme você escala com o aumento do volume de requisições, é preciso colocar novos nodes no ar; e cada novo node precisa ser construído incluindo aquela longa lista de funcionalidades, o que cria ineficiências e custos incômodos \(novamente, no lado mais barato, rodar um node custa $1.000/mês\).
- **Casos extremos**; como o node não tem proteções básicas, uma única query pode derrubar sozinha o seu node.

<ExternalVideo
  url="https://vimeo.com/775874968"
  provider="vimeo"
  providerUid="775874968"
/>

### \(4\) Nodes exigem manutenção em tempo integral
Em média, a cada 5 dias, os nodes podem apresentar problemas como:

- Vazamentos de memória
- Problemas de armazenamento de dados
- CPUs no limite
- Peering inconsistente
- Bancos de dados internos corrompidos
- Problemas na transmissão de transações
- Bugs + regressões
- 1 em cada 6 "releases estáveis" vem com problemas

Cada problema exige tempo significativo para diagnosticar, investigar e corrigir, o que significa [muito menos tempo focado na experiência de usuário do seu front-end](https://www.alchemy.com/case-study/zerion).

<CalloutBlock>

"Trabalhar com a Alchemy nos ajudou a economizar o equivalente a três engenheiros em tempo integral, que de outra forma estariam sempre focados na manutenção de infraestrutura." - Evgeny Yurtaev, CEO e Co-Founder, [Zerion](https://www.alchemy.com/dapps/zerion)

</CalloutBlock>

<ExternalVideo
  url="https://vimeo.com/775874996"
  provider="vimeo"
  providerUid="775874996"
/>

### \(5\) A eficácia dos nodes depende de navegar com sucesso por upgrades de rede ou hard forks de tempo imprevisível
Upgrades de rede e hard forks acontecem no cronograma do protocolo, não no seu. Cada um exige preparação significativa, e errar pode significar nodes derrubados, com impacto prejudicial.

<CalloutBlock>

"Antes de integrarmos com a Alchemy, rodávamos nossa própria infraestrutura de blockchain. Essa abordagem era impossível de manter e escalar sem problemas. Qualquer atualização em nível de indústria levava horas para implementarmos e causava dor de cabeça em toda a empresa." - Evgeny Yurtaev, CEO & Co-Founder, Zerion

</CalloutBlock>

## Padrões comuns de arquitetura de infraestrutura e por que falham

Rodar infraestrutura de nodes confiável é intrinsecamente desafiador, e boa parte da arquitetura comum do web3 é ineficaz para criar confiabilidade:

### Rodar um único node
É [mais simples de configurar, mas sujeito a um único ponto de falha](https://www.alchemy.com/overviews/running-your-own-node), sem heterogeneidade nem redundância. O uptime de um único node pode ser medido em apenas 72%, e escalar um único node é altamente ineficiente.

### Rodar um node com backup
Isso [cria um pouco mais de redundância do que um único node](https://www.alchemy.com/overviews/alternative-rpc-endpoint), mas ainda sem heterogeneidade \(sem diversidade de sistemas\), e frequentemente, uma requisição que derruba o primeiro node também derruba o segundo. Os problemas de escalabilidade continuam existindo, e você introduziu problemas de [**precisão de dados**](https://alchemy.com/blog/data-accuracy), o que significa que os nodes retornarão respostas diferentes, já que a maioria dos sistemas não consegue garantir que cada node esteja na mesma block head \(ou até mesmo na mesma chain\).

### ‍**Load balancing entre uma frota de nodes**

Esse modelo cria mais redundância, mas ainda sem heterogeneidade. Os problemas de precisão de dados e escalabilidade persistem \(uma série de retries vai derrubar toda a frota de nodes\).

<ExternalVideo
  url="https://vimeo.com/775875017"
  provider="vimeo"
  providerUid="775875017"
/>

<EmbeddedTable
  table={{
    columns: [
      { key: "1", width: 200, title: "", dataType: "object" },
      { key: "2", width: 200, title: "Reliability", dataType: "object" },
      { key: "3", width: 200, title: "Scalability", dataType: "object" },
      { key: "4", width: 200, title: "Data accuracy", dataType: "object" },
    ],
    data: [
      {
        "1": { title: "<p><strong>Running one node</strong><br/>Heterogeneity<br/>Redundancy</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Lacks heterogeneity and redundancy</p>", tooltip: "", icon: "" },
        "3": { title: "<p>Cumbersome to spin up new nodes</p>", tooltip: "", icon: "" },
        "4": { title: "<p>Yes! Has data accuracy</p>", tooltip: "", icon: "" },
        id: 0,
      },
      {
        "1": { title: "<p><strong>Running one node with a backup</strong><br/>Heterogeneity<br/>Redundancy</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Lacks heterogeneity and redundancy</p>", tooltip: "", icon: "" },
        "3": { title: "<p>Cumbersome to spin up new nodes</p>", tooltip: "", icon: "" },
        "4": { title: "<p>No data accuracy</p>", tooltip: "", icon: "" },
        id: 1,
      },
      {
        "1": { title: "<p><strong>Load balancing across a fleet of nodes</strong><br/>Heterogeneity<br/>Redundancy</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Lacks heterogeneity and redundancy</p>", tooltip: "", icon: "" },
        "3": { title: "<p>Cumbersome to spin up new nodes</p>", tooltip: "", icon: "" },
        "4": { title: "<p>No data accuracy</p>", tooltip: "", icon: "" },
        id: 2,
      },
    ],
  }}
/>

### Nodes frequentemente caem e são muito, **muito incômodos de consertar.**

Se ainda não ficou claro, muitas "soluções" para conectar à blockchain não oferecem heterogeneidade ou redundância suficientes e, por isso, acabam falhando. A falha tem ramificações graves.

<CalloutBlock>

"Antes da Alchemy, sofríamos ao gerenciar infraestrutura backend que consumia recursos de desenvolvimento desnecessariamente - e outras plataformas de desenvolvedor eram insuficientes na variedade de soluções que ofereciam. Incidentes relacionados a nodes representavam quase todos os nossos incidentes de plantão." - Brad Bayliss, Lead Technical Manager, Enjin

</CalloutBlock>

Nodes podem exigir dias ou semanas de tempo de recuperação até voltarem a funcionar. Esses problemas são caros, difíceis de resolver e exigem trabalho concentrado de toda a equipe.

Em 2019, a BlockCypher tentou navegar pelo Constantinople Hard Fork do Ethereum. Eles se depararam com um erro de dados ausentes e não conseguiram diagnosticar a causa raiz. Sofreram **mais de um mês de indisponibilidade** e, no fim, tiveram que basicamente recomeçar do zero.

Não deixe isso acontecer com você ;\)

Quanto mais heterogênea e redundante for sua infraestrutura web3, mais confiável ela será.

## Como a Alchemy constrói para confiabilidade em escala

<CalloutBlock>

"Sem dúvida, a Alchemy foi a única provedora com um conjunto abrangente de ferramentas que nos permite escalar sem atritos, com confiabilidade ininterrupta, fazendo milhares de chamadas por dia." - Kyle Gusdorf, Software Engineer, Decentral Games

</CalloutBlock>

[O Cortex engine da Alchemy combina sistemas customizados, escaláveis e distribuídos](https://alchemy.com/overviews/blockchain-node-providers) que viabilizam confiabilidade e escalabilidade, ao mesmo tempo em que permitem que nossa API funcione como um único node, garantindo assim a precisão dos dados.

### O Cortex alcança redundância e heterogeneidade com sistemas escaláveis e diversos

<ExternalVideo
  url="https://vimeo.com/775877885"
  provider="vimeo"
  providerUid="775877885"
/>

### Sistemas redundantes e heterogêneos para minimizar requisições de dados nos nodes  
A infraestrutura web2 cria confiabilidade e escalabilidade removendo o armazenamento de dados dos servidores e criando centros de armazenamento externos.

No entanto, por causa da natureza singular da arquitetura de nodes, remover o armazenamento de dados dos nodes é essencialmente impossível.

Para criar confiabilidade e escalabilidade, o Cortex engine da Alchemy usa uma arquitetura avançada, chamada infraestrutura secundária, para replicar os dados dos nodes.

<ImageBlock
  src="https://media.alchemy.com/1704726829-supernode-secondary-infrastructure.jpg"
  alt="Diagrama da infraestrutura secundária do Cortex replicando dados de nós"
  width={1920}
  height={1080}
  caption="Infraestrutura secundária do Cortex"
/>

O Vox Nodi, a camada de coordenação do Cortex, executa verificações constantes no sistema para garantir que a infraestrutura secundária tenha os dados mais recentes e, assim, qualquer requisição por dados, por exemplo, número do bloco, logs de transação, recibos de transação, será precisa.

Ao rotear as requisições primeiro para a infraestrutura secundária, os nodes ficam protegidos e sua "carga de trabalho" é reduzida.

<ImageBlock
  src="https://media.alchemy.com/1704726923-routing-requests-to-secondary-infrastructure.jpg"
  alt="Roteamento de requisições para infraestrutura secundária"
  width={1920}
  height={1080}
  caption="Roteamento de requisições para infraestrutura secundária"
/>

A maioria das requisições pode ser atendida pela infraestrutura secundária, e apenas casos extremos serão roteados para os nodes.

Vamos a um exemplo:

Usuários querem informações sobre vários tipos de dados e blocos:

- Usuário 1 pede dados de Transactions até o Block 82
- Usuário 2 pede dados de Logs a partir do Block 85
- Usuário 3 pede dados de Blocks a partir do Block 92

<ImageBlock
  src="https://media.alchemy.com/1704727109-secondary-infrastructure-example.jpg"
  alt="Diagrama da infraestrutura secundária atendendo requisições enquanto os nós tratam casos extremos"
  width={1920}
  height={1080}
  caption="Exemplo de infraestrutura secundária"
/>

A requisição do Usuário 1 pode ser atendida pelo sistema de infraestrutura secundária. \(É importante notar que, se uma requisição como essa atingisse um node diretamente, o node cairia, enquanto o sistema de infraestrutura secundária consegue lidar com essa carga sem problemas\).

A requisição do Usuário 2 também pode ser atendida pela infraestrutura secundária.

A requisição do Usuário 3 não pode ser atendida via infraestrutura secundária, porque o sistema ainda não tem os dados mais recentes de Blocks a partir do Block 92. A requisição do Usuário 3 será então atendida pelos nodes.

Neste exemplo, a experiência dos Usuários 1, 2 e 3 é exatamente a mesma. Não há diferença de tempo de resposta entre uma requisição atendida via infraestrutura secundária ou diretamente pelos nodes. Mas, ao rotear as requisições primeiro para o sistema de infraestrutura secundária, os nodes ficam protegidos e sua "carga de trabalho" é reduzida.

<CalloutBlock>

"A Alchemy nos permitiu eliminar a necessidade de usar infraestrutura secundária / de backup. A Alchemy nunca cai, e o uptime é extremamente consistente. A plataforma deles funciona perfeitamente para nós." - Johnny Rhea, Co-Founder & CTO, Element.Fi

</CalloutBlock>

### Sistemas redundantes e heterogêneos para execução de código
Como a Ethereum Virtual Machine \(EVM\) é Turing completa, é possível solicitar que os nodes executem código. Como os nodes não conseguem se autorregular, há um potencial constante de uma requisição arbitrária derrubar toda uma frota de nodes.

Para proteger contra isso, a Alchemy deduplica e armazena todas as requisições que nosso sistema já respondeu anteriormente.

Isso significa que apenas uma requisição genuinamente nova será executada nos nodes, e, fora isso, a grande maioria das requisições pode ser executada por esses sistemas de armazenamento.

<EmbeddedTable
  table={{
    columns: [
      { key: "1", width: 200, title: "Node Type", dataType: "object" },
      { key: "2", width: 200, title: "Data Coverage", dataType: "object" },
    ],
    data: [
      {
        "1": { title: "<p>Geth Archive Node</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Since genesis</p>", tooltip: "", icon: "" },
        id: 0,
      },
      {
        "1": { title: "<p>Geth Full (Fast) Node</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Most recent 2,000 blocks</p>", tooltip: "", icon: "" },
        id: 1,
      },
    ],
  }}
/>

<ImageBlock
  src="https://media.alchemy.com/1704727753-mudit-gupta-tweet.png"
  alt="Tweet de Mudit Gupta sobre balanceamento de carga"
  width={846}
  height={242}
  caption="Tweet de Mudit Gupta sobre balanceamento de carga"
/>

### Nodes heterogêneos, especializados para requisições diferentes
Além dos sistemas de infraestrutura secundária, a Alchemy adiciona heterogeneidade com tipos distintos de node. Nos cenários atípicos em que a infraestrutura secundária não consegue responder a uma requisição, o sistema recorre ao node mais escalável.

A Alchemy [roda múltiplos tipos de node](https://www.alchemy.com/overviews/what-is-an-ethereum-node), incluindo:

- **Light:** baixa apenas os cabeçalhos de bloco, o mínimo de dados necessário para transacionar na rede. Nodes light conseguem interagir com a rede de forma eficiente e economizam megabytes de banda e gigabytes de armazenamento, mas são limitados por não terem acesso aos dados completos.
- **Full**: tem tudo o que precisa para verificar que os blocos na rede estão corretos e pode interagir com qualquer [smart contract](https://www.alchemy.com/docs/how-to-deploy-a-smart-contract-to-the-sepolia-testnet) e implantar o seu próprio. Nodes full exigem recursos significativos de computação e banda.
- **Archive:** vai um passo além de um node full. Enquanto um node full descarta entradas que não precisa mais verificar, o node archive mantém tudo \(terabytes de dados extras\). Esses detalhes são ótimos para consultar informações com mais eficiência e úteis para algumas aplicações, mas são excessivos na maioria dos casos.
- **Debug:** nodes debug vão ainda mais longe que um node archive, armazenando mais informações do que qualquer outro tipo de node, para que você possa percorrer a execução de um [smart contract](https://www.alchemy.com/overviews/solidity-smart-contract) em detalhes extremos.

<ImageBlock
  src="https://media.alchemy.com/1704727971-alchemy-runs-multiple-types-of-nodes.jpg"
  alt="A Alchemy opera múltiplos tipos de nós"
  width={1920}
  height={1080}
  caption="A Alchemy opera múltiplos tipos de nós"
/>

Propriedades distintas dos tipos de node os tornam bons em coisas diferentes, então, se um node não conseguir responder a uma requisição, os outros provavelmente ainda estão saudáveis e bem adequados para responder.

Por exemplo, se houver uma requisição pelos dados mais recentes, que talvez ainda não estejam registrados na infraestrutura secundária, essa requisição pode ser roteada para um node fast, e o node archive ficará "protegido", já que vasculhar os dados do node archive seria significativamente mais custoso.

Para facilitar colocar novos nodes no ar conforme necessário, o Cortex engine tira "snapshots" dos nodes, de modo que, para criar um novo node, o sistema pode partir do "checkpoint" mais recente, encurtando significativamente o processo de sincronização.

<EbookCta
  eyebrow="Guia gratuito"
  title="Construir vs. Comprar: Infraestrutura Blockchain"
  description="Antes de contratar uma equipe de infra, leia isto: construir internamente pode custar $850K–$1M+ por ano antes de atender uma única requisição em produção. Veja o detalhamento completo dos custos."
  ctaLabel="Baixar o guia"
  ctaHref="/resources/build-vs-buy"
  coverImage={{
    src: "https://media.alchemy.com/ebooks/cta-build-vs-buy.png",
    alt: "Build vs. Buy ebook cover",
  }}
/>

### Clients heterogêneos para mitigar o impacto de bugs
Por fim, a Alchemy roda diferentes implementações do client Ethereum, incluindo [geth](https://www.alchemy.com/overviews/what-is-a-geth-node-and-how-to-run-one), Erigon e Parity. Isso essencialmente triplica o trabalho de manutenção de backend necessário, mas tem grande valor a serviço da heterogeneidade: a chance de esses clients terem o mesmo bug é essencialmente zero.

## Criando confiabilidade por meio de **redundância e heterogeneidade**

Na Alchemy, dedicamos centenas de milhares de horas para engenheirar o Cortex, um conjunto complexo de sistemas construídos do zero para ser heterogêneo e redundante, aumentando drasticamente nossa tolerância a falhas e garantindo que possamos responder com confiabilidade a qualquer requisição de blockchain.

<ImageBlock
  src="https://media.alchemy.com/1704728098-use-alchemy-rpc.png"
  alt="Use Alchemy RPC para seus NFTs"
  width={856}
  height={190}
  caption="Use Alchemy RPC para seus NFTs"
/>

<CalloutBlock>

"Infraestrutura que é confiável e escalável ao mesmo tempo, para que possamos continuar no ar quando nossos clientes mais precisam de nós - isso é enorme para a Collab.Land. A Alchemy é a referência aqui." - Raymond Feng, CTO, Collab.Land

</CalloutBlock>

<ImageBlock
  src="https://media.alchemy.com/1704728160-use-alchemy-rpc-for-your-dapps.png"
  alt="Use Alchemy RPC para seus apps"
  width={846}
  height={214}
  caption="Use Alchemy RPC para seus apps"
/>

Levamos anos para construir os sistemas complexos e interdependentes que tornam essa confiabilidade possível. Construir para controlar a confiabilidade é extremamente desafiador, mas contar com infraestrutura confiável é crucial para o sucesso do seu app.

Ao explorar opções de infraestrutura, uma das primeiras perguntas que você deve fazer a um provedor é: **"Quão heterogênea e redundante é a sua infraestrutura? E que evidências você pode me mostrar que comprovem a confiabilidade dos seus sistemas?"**

[Benchmarks públicos de provedores de RPC](https://www.alchemy.com/benchmarks) podem ajudar a avaliar latência, taxas de sucesso e requisições que falharam, ao lado das alegações de arquitetura de um provedor.

O sucesso do seu app depende dessa escolha. Conte com a gente para ajudar!