O gateway de API desenvolvido internamente nos economizou 38% dos custos de chamadas a terceiros, mas acabamos encontrando problemas com a adaptação entre regiões.

Na semana passada, nossa equipe de ferramentas de comércio eletrônico no Sudeste Asiático acabou de analisar a conta de custos técnicos do Q1, e o colega responsável pela interface de pagamento quase pulou de alegria: após substituir o gateway terceiro-party por um desenvolvido internamente, o custo de chamadas de API caiu 38% em um mês. No entanto, durante o teste de fase de transição (grayscale) antes de uma promoção importante, a taxa de sucesso de pagamento dos usuários no nó de Cingapura caiu repentinamente em 6 pontos percentuais. Demorou bastante para descobrir que a regra de fusão regional (cross-regional circuit breaking) do gateway não havia sido adaptada adequadamente.

Primeiro, vamos entender o que é um gateway construído internamente (self-built gateway).

Em resumo, você precisa escrever um próprio programa de entrada de tráfego que processe todos os pedidos de API externos, chamadas de retorno de terceiros e chamadas entre serviços, substituindo o serviço de gateway de terceiros que compramos anteriormente. A versão que estamos usando atualmente está rodando em 4 servidores remotos com processadores de 2 núcleos (4G), cada um capaz de suportar 1200 pedidos por segundo, o que cobre completamente as nossas necessidades diárias de 1,8 milhão de pagamentos e chamadas de sincronização de produtos.

Três benefícios concretos que você pode obter:

• Primeiro de tudo, o custo realmente pode ser reduzido. O gateway de terceiros que usávamos antes cobrava com base no número de chamadas, o que custava 2100 dólares por mês. Agora, com o servidor e o sistema de monitoramento que construímos internamente, o custo mensal é de menos de 1300 dólares, e ainda não somos afetados por aumentos de preços progressivos.
• Em segundo lugar, as regras são completamente definidas por nós mesmos. Antes, o controle de taxa de solicitação pelos gateways de terceiros era unificado, e durante as promoções tínhamos que solicitar temporariamente cotas de controle de taxa de solicitação para as interfaces de pagamento, o que levava 3 dias úteis para ser processado através de um pedido de serviço. Agora, podemos alterar as configurações no backend em apenas 10 segundos e as mudanças entram em vigor imediatamente.
• Finalmente, não é necessário usar terceiros para o processamento dos dados. Ao desenvolver ferramentas de comércio eletrônico, precisamos lidar com muitos chamados de retorno de pagamento dos usuários. Antes, todos os pedidos passavam pelos servidores de terceiros, mas agora todos os dados sensíveis são processados em nossos próprios servidores, o que reduziu significativamente os custos com conformidade.

Não se apresse em construir; primeiro veja os erros que já cometemos.

O primeiro problema foi a adaptação da rede entre diferentes regiões. No início, colocamos o nó principal do gateway em Cingapura, e quando abrimos a filial na Malásia, direcionamos todo o tráfego para lá. Como resultado, as solicitações dos usuários locais tinham que passar por Cingapura antes de serem enviadas para a Malásia, o que aumentava o atraso na rede em 200 ms. Muitos usuários desistiam antes mesmo de a página de pagamento ser carregada completamente. Levamos uma semana para configurar os nós de borda na Malásia.

O segundo problema é a omissão de regras de segurança. Anteriormente, os gateways de terceiros incluíam por padrão proteção contra DDoS e interceptação de solicitações maliciosas, mas quando construímos o nosso próprio sistema, esquecemos de adicionar essa proteção. No terceiro dia de funcionamento, nosso sistema recebeu 200.000 solicitações inválidas de robôs de busca, o que quase causou o colapso da interface de gestão de estoque.

O terceiro problema é que o custo de operação e manutenção é mais alto do que o esperado. Antes, quando havia problemas com o gateway de terceiros, bastava contatar o suporte ao cliente. Agora, nós três desenvolvedores de backend temos que revezar nos turnos noturnos para monitorar o gateway, e no mês passado, apenas a resolução de falhas no gateway consumiu 15% do tempo de trabalho de todos.

Que tipo de equipe é adequado para se juntar, e com que tipo não vale a pena perder tempo

Se a sua equipe realizar mais de 1 milhão de chamadas de API por dia em média, ou se tiver uma grande quantidade de dados sensíveis para processar, ou se estiver cansado dos limites de tráfego e dos processos de ticket de gateways terceiros, então a construção de um gateway próprio definitivamente vale a pena.

Mas se a sua equipe tem menos de 2 desenvolvedores de backend, ou se o negócio ainda está em uma fase de rápida experimentação e as regras das interfaces mudam a cada semana, realmente não há necessidade de gastar tempo com isso. É melhor usar um gateway de terceiros por enquanto; você pode trocar quando o negócio estiver mais estável.

3 dicas práticas para quem está montando pela primeira vez

1. Começe com um cenário único, não tente substituir tudo de uma vez. No início, transferimos apenas o tráfego da interface de pagamento para o nosso próprio gateway, e depois de duas semanas sem problemas, começamos a migrar outras interfaces gradualmente. Mesmo que surjam problemas, eles afetarão apenas o cenário de pagamento e não todo o site.
2. É essencial realizar testes de carga em diferentes regiões. Isso é ainda mais importante para negócios internacionais. Não basta testar apenas localmente antes de lançar o produto; procure pontos de teste no seu mercado-alvo e execute testes de carga contínuos (24 horas) para verificar se existem problemas com a latência ou a taxa de perda de pacotes.
3. Não economize no painel de monitoramento. Pelo menos, fique de olho nos três indicadores principais: o volume de solicitações, a taxa de sucesso e o atraso. Defina bem os limiares de alarme para que você não descubra que o gateway está desativado só quando os usuários começarem a reclamar.

Problemas comuns

Pergunta: É necessário escrever o código em Go ou Rust?
Não é necessário, nossa primeira versão foi escrita em Node.js e consegue suportar os picos de carga. Basta que sua equipe esteja familiarizada com o idioma de programação que for utilizado; você pode trocar para outra tecnologia caso surjam problemas de desempenho mais tarde.

Pergunta: Qual é melhor em comparação com os gateways dos fornecedores de nuvem?
Os gateways das empresas de cloud são mais flexíveis do que os de terceiros, mas ainda não oferecem a mesma liberdade do que aqueles construídos internamente. Se você não quer ficar vinculado a uma determinada empresa de cloud, construir seu próprio gateway pode ser a melhor opção.