Melhorando a Latência ao fazer tratamento de JSON (Marshalling)

No universo das transações financeiras, cada milissegundo conta. Quando lidamos com JSON em microsserviços sob alta carga, podemos ter picos de latência que ameaçam o Acordo de Nível de Serviço (SLA). Uma pequena mudança — que não é uma bala de prata, mas pode auxiliar esses serviços — está em uma otimização elegante utilizando a biblioteca padrão do Go.

Cenário fictício: Uma API de pagamentos Pix sob pressão

Imagine um microsserviço em Go que orquestra o processo de pagamento. Em horários de pico, a aplicação processava milhares de solicitações por segundo. Uma análise com as ferramentas de profiling do Go (pprof e go tool trace) revelou um culpado inesperado: a serialização de JSON.

Nosso handler HTTP parecia simples e idiomático:

// Versão Inicial - Ineficiente sob alta carga
func ProcessPixPaymentHandler(w http.ResponseWriter, r *http.Request) {
    transactionData := getTransactionData(r)

    response := PixResponse{
        TransactionID: transactionData.ID,
        Status:        "CONFIRMED",
        Details:       buildComplexDetailsStruct(transactionData),
    }

    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(response) // <-- O gargalo está aqui!
}

A linha json.NewEncoder(w).Encode(response) estava causando um grande número de alocações de memória a cada chamada. Sob alta concorrência, isso gerava uma imensa pressão sobre o Garbage Collector (GC), adicionando preciosos milissegundos de latência.

A solução: Reciclando Buffers com sync.Pool

Em vez de permitir que a biblioteca json alocasse um novo buffer de memória para cada resposta, por que não reutilizar buffers que já foram usados? É como levar uma sacola reutilizável ao supermercado em vez de pegar uma nova a cada compra.

// Pool de buffers para reutilização em toda a aplicação.
var bufferPool = sync.Pool{
    New: func() interface{} {
        return new(bytes.Buffer)
    },
}

// Versão Otimizada
func ProcessPixPaymentHandler(w http.ResponseWriter, r *http.Request) {
    transactionData := getTransactionData(r)

    response := PixResponse{
        TransactionID: transactionData.ID,
        Status:        "CONFIRMED",
        Details:       buildComplexDetailsStruct(transactionData),
    }

    // 1. Pega um buffer "reciclado" do pool.
    buf := bufferPool.Get().(*bytes.Buffer)
    buf.Reset()
    defer bufferPool.Put(buf)

    // 2. Codifica a resposta JSON no buffer reutilizável.
    err := json.NewEncoder(buf).Encode(response)
    if err != nil {
        http.Error(w, "Erro ao codificar a resposta.", http.StatusInternalServerError)
        return
    }

    // 3. Escreve o resultado do buffer para a resposta HTTP.
    w.Header().Set("Content-Type", "application/json")
    w.WriteHeader(http.StatusOK)
    w.Write(buf.Bytes())
}

Essa pequena alteração pode gerar grandes impactos:

• Menos Alocações: Reduz-se drasticamente a quantidade de memória alocada por requisição.
• Menos Pressão no GC: Com menos lixo para coletar, o Garbage Collector roda com menos frequência e por menos tempo.
• Respostas Mais Rápidas: O resultado final é uma redução na latência do endpoint nos momentos de maior tráfego.

Por que isso funciona tão bem?

1. sync.Pool é otimizado para objetos de curta duração: Cada processador mantém seu próprio pool local de objetos, permitindo que goroutines peguem e devolvam objetos sem disputar travas.
2. Buffers e JSON: Uma combinação perfeita: O json.Encoder do Go foi projetado para escrever em qualquer io.Writer. Um bytes.Buffer é um io.Writer em memória, tornando-o o candidato ideal.
3. Código amigo do GC é código amigo da Latência: Minimizar o trabalho do GC é fundamental para garantir a previsibilidade do tempo de resposta.

Quando NÃO Usar sync.Pool?

Use sync.Pool apenas quando o objeto tem vida curta e a criação do objeto é cara o suficiente para justificar a reutilização. Evite usá-lo para conexões de banco de dados ou objetos compartilhados de forma insegura entre goroutines.

E a regra de ouro: sempre chame Reset() no objeto antes de reutilizá-lo. Lembre-se sempre:

1. Medir antes, medir depois: Ferramentas como o pprof são essenciais para encontrar gargalos reais.
2. Latência e GC andam de mãos dadas: Em sistemas sensíveis à latência, escrever código que aloca menos memória é uma das otimizações mais eficazes.
3. sync.Pool é uma joia escondida: Para tarefas de serialização e I/O em memória, é uma ferramenta incrivelmente poderosa.