--- title: "Como avaliar provedores de infraestrutura blockchain dedicada" description: "Um checklist prático para avaliar infraestrutura blockchain dedicada: consistência, uptime, isolamento, região, flexibilidade e caminho de migração." --- # Como avaliar provedores de infraestrutura blockchain dedicada Escolher um provedor de infraestrutura blockchain dedicada é uma decisão que pode ter impacto duradouro por anos. A maior parte dos critérios que importam não aparece em uma demonstração de vendas. Eles aparecem depois que você está em produção e em escala. O provedor que parece mais barato por mês pode acabar custando mais em downtime, dados desatualizados e tempo de engenharia. Este guia apresenta as perguntas que vale a pena fazer antes de se comprometer, na ordem em que de fato importam. Use-o como um checklist para avaliar qualquer provedor, para que você possa fazer o deploy e escalar com confiabilidade. ## Comece pela consistência, não pela velocidade Todo provedor vai te dar um número de latência. Bem menos provedores vão te dizer o que acontece quando os nós deles discordam entre si. A falha que mais prejudica em produção não é a lentidão. É um nó que ficou atrás da ponta da cadeia e está servindo dados desatualizados com confiança. Pergunte como um provedor mantém as leituras consistentes entre nós redundantes, e quais garantias eles dão de que uma leitura reflete o estado atual da cadeia. Um provedor que roda nós [redundantes](/overviews/how-dedicated-blockchain-infrastructure-works) atrás de uma camada de consistência está resolvendo um problema que um único nó rápido não resolve. O que perguntar: Como vocês mantêm as leituras consistentes entre nós? O que acontece com minhas requisições quando um nó fica atrasado? ## Uptime, e a prova por trás dele Todo mundo alega alto uptime. A pergunta útil é em relação a que esse número é medido e se ele se manteve durante um evento real de estresse. Peça um número específico de uptime, como ele é medido, e como o provedor se saiu durante um momento recente de alto tráfego, como uma grande liquidação ou um upgrade de rede. Desempenho durante a calmaria é o básico esperado. Desempenho durante o pico é o produto de fato. O que perguntar: Qual é o seu [uptime medido](/benchmarks), e como vocês se saíram durante o último grande evento de estresse na rede? ## Isolamento e compliance Se você é uma equipe regulada ou financeira, o isolamento single-tenant é muitas vezes a razão pela qual você está considerando infraestrutura dedicada, ponto. Pergunte se a infraestrutura é de fato single-tenant, quais atestados de [compliance](https://trust.alchemy.com/) existem (SOC 2 Type II é o padrão comum), e se sua carga de trabalho fica isolada do tráfego de outros clientes. Infraestrutura compartilhada com um rótulo de "dedicada" não é a mesma coisa que isolamento real. O que perguntar: Isso é single-tenant? Quais atestados de compliance vocês têm? ## Posicionamento regional Para cargas de trabalho sensíveis à latência, onde a infraestrutura fisicamente fica muda seus números mais do que quase qualquer outro fator. Pergunte em quais regiões um provedor pode fazer deploy, se eles conseguem posicionar um cluster perto dos seus usuários ou da sua stack existente, e como a latência muda entre essas regiões. Um provedor preso a uma única região é uma escolha ruim para uma aplicação global ou sensível à latência. O que perguntar: Em quais [regiões](/benchmarks) vocês conseguem fazer deploy, e conseguem posicionar infraestrutura perto da minha stack? ## Flexibilidade: execução customizada e hardware A razão pela qual muitas equipes fazem self-host é o controle: tracers customizados, binários customizados, hardware dimensionado para a carga de trabalho delas. Um [provedor dedicado](/blog/introducing-dedicated-clusters) que vale a pena considerar permite manter isso. Pergunte se você pode rodar tracers e binários customizados, se o hardware é dimensionado para a sua carga de trabalho ou espremido em tiers fixos, e se cargas pesadas de archive e trace são limitadas. Se migrar para um provedor significa abrir mão do controle pelo qual você fez self-host, isso não é uma alternativa real. O que perguntar: Posso rodar tracers e binários customizados? O hardware é dimensionado para a minha carga de trabalho? ## Suporte e caminho de migração A melhor infraestrutura não vale nada se migrar para ela vira um projeto. Pergunte como funciona a migração, se você pode rodar em paralelo com sua configuração atual antes de fazer o cutover, e qual failover existe se a capacidade dedicada tiver um problema. O que perguntar: Como funciona a migração, e qual é o fallback se a capacidade dedicada falhar? ## Um checklist rápido de avaliação - Consistência: Como as leituras são mantidas atualizadas entre nós? Dados desatualizados são a falha de produção mais comum. - Uptime: Uptime medido e comportamento sob estresse? O pico é o teste de verdade, não a calmaria. - Isolamento: Single-tenant? SOC 2 Type II? Muitas vezes é a razão inteira para optar por dedicado. - Região: Quais regiões, quão perto da minha stack? O maior fator isolado em latência. - Flexibilidade: Tracers customizados, binários, hardware dimensionado? Mantém o controle pelo qual você fez self-host. - Suporte: Caminho de migração e failover? Uma migração difícil apaga o benefício. Nossos [Dedicated Clusters](/dedicated-clusters) são construídos em torno de vários desses critérios: isolamento single-tenant, consistência exata a nível de bloco, execução customizada e failover automático para uma frota compartilhada. A forma certa de usar este guia é confrontar todo provedor, inclusive nós, com as mesmas perguntas. ## Comece agora Se você está avaliando infraestrutura dedicada, comece com este checklist e depois compare com [Node RPC vs. Dedicated Clusters](/overviews/dedicated-vs-shared-nodes). Quando estiver pronto para conversar sobre o encaixe para sua carga de trabalho, [fale com nossa equipe](/contact-sales-dedicated-clusters). ## Perguntas frequentes ### O que devo procurar em um provedor de infraestrutura blockchain dedicada? Em ordem de impacto: consistência de leitura entre nós, uptime comprovado sob estresse, isolamento single-tenant genuíno e compliance, posicionamento regional perto dos seus usuários, flexibilidade para execução customizada e hardware, e um caminho de migração de baixo risco com failover. ### O que caracteriza um provedor de nó RPC de alto desempenho? Leituras consistentes entre nós redundantes, baixa latência regional medida onde seus usuários estão, baixas taxas de erro sob carga, e margem que se mantém durante picos de tráfego, não só em condições normais. ### Como sei se um provedor de nó RPC é confiável? Peça um número de uptime medido e como ele foi calculado, evidências de desempenho durante um evento recente de estresse na rede, e qual redundância e failover existem por trás do endpoint. ### Infraestrutura dedicada é sempre melhor do que compartilhada? Não. Se sua carga de trabalho roda confortavelmente em um plano compartilhado elástico, essa costuma ser a escolha melhor e mais econômica. Dedicado vale a pena por razões específicas e duradouras: execução customizada, isolamento single-tenant, uma região que você não conseguiria alcançar de outra forma, ou volume sustentado.