DEV Community: Yury Cavalcante

Reescrevendo Legados #01

Yury Cavalcante — Sat, 24 Jan 2026 23:10:48 +0000

Contexto

Na iugu, temos um processo rigoroso de cadastro e KYC (Know Your Customer) para todos os nossos clientes. Este processo é fundamental para a conformidade e segurança, e envolve a verificação de diversos documentos. É justamente nesse contexto que notamos um envio excessivo de comunicações, identificado por dois fatores principais: nosso serviço de e-mail teve o número de envios mensais extrapolado muito antes do esperado, e nossos clientes estavam relatando o recebimento de lembretes repetidos.

Dados os dois fatores, o mais lógico seria analisar todos os processos responsáveis pelo envio de e-mails do nosso monolito, e isso nos levou a um worker no sistema que verificava todas as contas dos clientes com documentos pendentes.

Separarei os tópicos do artigo pelos problemas identificados no worker:

Query ineficiente na busca de contas com documentos pendentes.
Falta de granularidade nos processos para cada conta encontrada.
Ausência de observabilidade.

É importante ressaltar que o Claude Code (no meu caso, é o que utilizo) poderia varrer o sistema para encontrar todos esses problemas identificados, inclusive em mais de um worker, mas é crucial trabalhar em conjunto com a inteligência artificial. Acredito que, apesar da assistência da IA, quem detém o contexto, a lógica e as decisões de design importantes é o programador. Então, não deixe de acompanhar de perto as decisões tomadas pelo seu agente, questioná-las e ir além.

Query ineficiente na busca de contas com documentos pendentes.

A query original:

customers = Customer.with_verification_request
                    .includes(:customer_attributes)
                    .where('customer_attributes.key = "verification_due_date"')
                    .where('customer_attributes.value < ?', 10.days.from_now)
                    .references(:customer_attributes)

Ao otimizar a query, já conseguiríamos um resultado mais performático. Para aqueles que não estão acostumados com Rails, podemos "traduzir" a sintaxe do Rails para SQL puro com o método built-in do Rails chamado .to_sql:

SELECT customers.*
FROM customers
JOIN customer_attributes ON customer_attributes.customer_id = customers.id
WHERE customer_attributes.key = 'verification_due_date'
  AND customer_attributes.value < CURRENT_DATE + INTERVAL '10 days';

Identificação dos problemas:

includes carrega todos os dados de customer_attributes na memória
Falta de filtros essenciais na query (status, customers não verificados)

Esses são os problemas essencialmente ligados à query. No entanto, em seguida, temos o bloco de código que traz redundância e lentidão devido à forma como a query foi construída.

customers.find_each do |customer|
  next unless customer.verified?
  # processamento
end

find_each carrega objetos Customer completos (todas as colunas)
Filtros aplicados em Ruby após carregar dados (next unless customer.verified?)

Vamos destrinchar as soluções em forma de resposta aos problemas listados. Lembrando que estas são apenas algumas das possíveis abordagens dentro da situação.

Solução para o carregamento excessivo de dados com includes:

Podemos trocar o uso de includes por joins porque:

Não carrega associações desnecessárias.
Apenas filtra os registros.

Isso reduz o uso de memória significativamente.

Solução para a falta de filtros essenciais na query:

Podemos mover todas as condições do código para filtros na nossa query:

verified: true - antes era customer.verified? em Ruby.
status: [...] - para garantir apenas clientes pré-aprovados.

E, ao tentar utilizar os índices existentes no banco para as tabelas customers e customer_attributes.

Agora temos uma query um pouco maior em linhas de código, porém mais eficiente (traz apenas as contas que deveríamos atuar).

Resultado:

customer_ids = Customer.with_verification_request
                       .joins(:customer_attributes)
                       .where('customer_attributes.key = "verification_due_date"')
                       .where('customer_attributes.value < ?', 10.days.from_now)
                       .where(verified: true)
                       .where(status: ['approved', 'active', 'processing'])
                       .where('NOT EXISTS(
                         SELECT 1 FROM customer_attributes ca
                         WHERE ca.customer_id = customers.id
                         AND ca.key = "disabled_subaccount"
                         AND customers.parent_id IS NOT NULL
                       )')
                       .pluck('customers.id')

Essa é a query final, com algumas observações:

Estamos buscando e selecionando apenas os IDs dos clientes com pluck('customers.id'). Agora, a variável que vamos iterar é apenas um array de IDs: customer_ids.
Na iugu, um cliente pode ter subcontas associadas a ele. Por isso, temos uma subquery para excluir clientes com subcontas desabilitadas.

Comparando o tamanho dos dois arrays que deveríamos iterar:

Query velha (com customers sendo carregados em memória):

Query nova (apenas os ids):

Na data de escrita deste artigo, temos um array aproximadamente 7,5 vezes menor que o antigo, e cada um desses itens agora é um dado muito mais simples: um ID.

Falta de granularidade nos processos para cada conta encontrada

O problema aqui era que, se uma exceção ocorresse durante o processamento de uma conta, toda a task falhava e era reiniciada pelo Sidekiq. Na reinicialização, a query era executada novamente, retornando as mesmas contas, incluindo aquela que havia falhado, causando um loop de reinicializações. Enquanto isso, clientes que já haviam sido processados com sucesso recebiam e-mails repetidos.

A ideia aqui foi bem simples: quebrar o processamento em unidades menores e independentes.

Ao invés de processar tudo em um único loop, decidimos adicionar um worker para performar a operação necessária para cada uma das contas dentro do array de IDs. Essa abordagem traz vantagens como:

Isolamento de falhas: Se o processamento de uma conta específica falhar, apenas o worker responsável por ela será afetado, e não a task inteira. Os demais workers continuarão a processar suas respectivas contas sem interrupção.
Retry independente: O Sidekiq pode re-tentar apenas o worker que falhou, sem a necessidade de reprocessar todo o lote de clientes. Isso economiza recursos e evita o envio repetido de comunicações para clientes já processados.

Fomos disso:

class CustomersPendingVerificationTask
  include Sidekiq::Worker

  def perform
    accounts = # Antiga query onerosa

    accounts.find_each do |account|
      next unless account.is_verified?
      result = Cmd::Account::Documents.new(account).call # Processo onde era possível acontecer uma exceção
      unless result[:all_documents_valid]          AccountNotificationMailerWorker.perform_async(:pending_documents, account.id) # Disparo do e-mail
      end
    end

    ...
  end
end

Para isso:

class CustomersPendingVerificationTask
  include Sidekiq::Worker

  def perform
    customer_ids = # Query otimizada...

    customer_ids.each do |customer_id|
      CustomerPendingVerificationWorker.perform_async(customer_id)
    end
  end
end

O código do Worker criado agora possui o processamento necessário para verificar os documentos do cliente.

class CustomerPendingVerificationWorker
  include Sidekiq::Worker

  def perform(customer_id)
    customer = Customer.find_by(id: customer_id)

    return unless customer.present?

    result = Services::Customer::VerificationChecker.new(customer).call

    unless result[:verification_complete]
      NotificationMailerWorker.perform_async(:pending_verification, customer.id)
    end
  end
end

E isso por si só, matou o problema dos múltiplos disparos repetidos, e também o gasto desnecessário com comunicações extras que estava fora do radar.

Um bônus adicionado aqui foi monitoria, coloquei TaskLogs para: registrar execução e identificar ínicio e final do processo.

class CustomersPendingVerificationTask
  include Sidekiq::Worker

  def perform
    start_task

    ... # Query e chamada do worker

    finish_task
  end

  private

  def start_task
    TaskLog.start_batch(
      task_name: 'CustomersPendingVerificationTask',
      batch_id: nil,
      target_type: "Customer"
    )
  end

  def finish_task
    TaskLog.finish_batch(
      task_name: 'CustomersPendingVerificationTask',
      batch_id: nil,
      target_type: "Customer"
    )
  end
end

Com isso finalizo com a ideia de que, uma pequena refatoração em dois arquivo pode salvar uma boa grana e dor de cabeça com base de clientes.

Ideia

Yury Cavalcante — Thu, 18 Apr 2024 23:09:11 +0000

Ideia

Uma plataforma que possua comunidades. Em essência, uma comunidade é um
conglomerado de contas que praticam um X esporte/prática em N endereços.
Usuários vão utilizar para achar comunidadese no que adentrararem numa comunidade Y,
será criada uma Conta para o usuário que representa a participação do Usuário na Comunidade Y.
Comunidades são criadas por uma Conta de um Usuário, que podem escolher aceitar ou não a Conta que está tentando adentrar.
A Conta criadora de uma comunidade possui um "cargo" de dono da comunidade, enquanto os participantes terão cargo de "Membro"

---------------------------------------

Requerimentos obrigatórios para uma Comunidade existir

Nome da comunidade
Ao menos um endereço
Ao menos um usuário
Ao menos uma prática informada
Timeline com posts dos usuários

Requerimentos opcionais

Descrição
Imagem de "perfil" da comunidade

Ideias de validações para uma comunidade legítima

Endereço deve ser um local público

--------------------------------------

Requerimentos obrigatórios para um Usuário existir

Nome
Sobrenome
E-mail
CPF

Requerimentos opcionais

Endereço
Ao menos uma prática informada

Ideias de validações para um Usuário legítimo

Validação do CPF
Validação do e-mail
Validação do endereço

-------------------------------------

Requerimentos obrigatórios para uma Conta existir

Cargo
Permissões

-------------------------------------

Requerimentos obrigatórios para uma Prática existir

Nome
Categoria (E-sport, Esporte, Exercício, etc)

-------------------------------------

O usuário se cadastra na plataforma
O usuário com apenas informações obrigatórias terá acesso a comunidades com maior média de pessoas e práticas
O usuário com informações opcionais (endereço e uma prática informada) terá acesso a comunidades perto do endereço e práticas cadastradas.

O Usuário que criar uma Comunidade, terá uma Conta atrelada a Comunidade criada e sua Conta com cargo de Dono e permissões de Dono.
O Usuário pode pedir para entrar uma Comunidade, caso permitido terá uma Conta atrelada a Comunidade e com cargo de Membro com permissões de Membro.
O Usuário pode ter N Contas (Ou seja, participar de múltiplas comunidades)
O Usuário pode interagir na timeline da Comunidade, bem semelhante ao Twitter. (necessário detalhar como será elaborado as mensagens dos usuários nessa timeline)

Priority Queue em Ruby

Yury Cavalcante — Thu, 04 Apr 2024 00:18:04 +0000

Estive estudando o básico de estrutura de dados e algoritmos novamente durante minhas streams, meus estudos acabaram casando com um vídeo do Augusto Galego sobre otimizar uma solução de um desafio Leetcode utilizando a estrutura de dados Heap.

No vídeo o Augusto resolve usando a própria lib nativa do Python. Em Ruby não existe Heap nativo, porém, existe essa lib de algoritmos do Kanwei. Nela temos as estruturas abstratas e concretas: Priority Queues, Heap (min e max), Stack e etc.

Decidi fazer minha implementação de Priority Queue usando Min Heap/Max Heap, mas antes de sairmos falando sobre a implementação vamos definir o que são essas estruturas que estamos tanto falando, Heap pra lá, Priority Queue pra cá...

Ah, e todo esse processo foi gravado durante uma stream. Se te interessar está aqui os links.

Priority Queue

Uma estrutura de dados abstrata. Quase idêntica ao conceito de Queues (FIFO), porém, a saída de um elemento da Priority Queue respeita uma prioridade contida em cada elemento da fila.

Heap

A estrutura de dados que vamos utilizar na Priority Queue. Ela é uma árvore binária balanceada, e podemos representar ela com um array pra tornar as funções da fila possíveis. Dada a seguinte árvore binária:

Representamos com o seguinte array:
[2, 10, 12, 122, 13, 100]

Nota-se que os números azuis na imagem é o index dos arrays.
E a imagem também nos leva ao próximo tópico sobre Heaps...

Min/Max Heap

Uma heap pode ordenar sua árvore do menor para o maior como na imagem do tópico acima, chamamos de Min Heap. Mas também pode ser possível ordená-la de forma crescente:

Acima, o exemplo de uma Max Heap, que ficaria assim num array
[122, 13, 100, 2, 10, 12]

Inserindo elementos na Heap

Sempre que formos inserir um novo elemento na árvore (ou no array se preferir), temos que rebalancear a árvore caso necessário. Se inserirmos um elemento 6 (com prioridade 6), ela ficaria desbalanceada. O que nos leva a necessidade de compararmos o elemento pai do recém inserido, fazendo um processo chamado de bubble up (ou sift up, heap up:

Elemento pai maior?
- Sim? Trocamos de posição o elemento inserido com o pai. (Fazer esse passo até resposta negativa)
- Não? Finalizamos o processo, temos uma árvore balanceada pós push.

Removendo elementos da heap

Quando removemos um item da heap, vamos rebalancear da mesma forma. Trocamos o elemento da raiz da Heap com o último elemento (index 0 com o último index do array), removemos o último elemento do array e então vamos para o processo de descer o elemento da raíz até o seu devido lugar na árvore chamado de bubble down (ou sift down, heap down):

Elementos filhos esquerdo ou direito menor?
- Sim? Priorizar o filho que tiver menor valor contido. Repetir esse passo até resposta negativa.
- Não? Processo finalizado e temos uma árvore balanceada.

Implementação

Esse com certeza não é o código mais performático de uma Priority Queue, estou compartilhadno e usando tanto este post quanto minha stream como forma de documentar o aprendizado. Pretendo melhorar o código e ele está disponível no repositório de estudos de algorimos no meu github. Isso obviamente não quer dizer que não estou sucinto a comentários sugerindo melhorias, todos são muito bem vindos! :)

Os elementos

Criei uma classe que representaria os elementos da Heap, e nele temos duas importantes coisas a se notar.

class Element
  attr_accessor :data, :priority

  def initialize(data, priority = data)
    @data, @priority = data, priority
  end

  def <=>(elem)
    @priority <=> elem.priority
  end
end

É possível inicializar um elemento com uma prioridade customizável, mas caso não é inicializada com a prioridade explícita, usaremos o próprio dado como prioridade. Isso vai nos ajudar na criação de uma Heap com inteiros por exemplo: um Element.new(10) já define o elemento 10 com prioridade 10.
Uma forte característica da Heap é que estaremos comparando o tempo todo os elementos (maior que, menor que). Criamos uma função que sobreescreve o spaceship operator (<=>). O que ele faz é simples:

a <=> b
#  se a < b retorna -1
#  se a = b retorna 0
#  se a > b retorna return  1
#  se a e b não são comparáveis, retorna nil

Quando utilizarmos element1 <=> element2 ele vai nos retornar um desses 4 valores. Esse valor vai determinar a posição de um elemento após ser removido da fila, ou enfileirado. Isso vai nos ajudar na lógica de bubble up ou bubble down

A Priority Queue

Vamos por partes...

class PriorityQueue
  attr_accessor :elements

  def initialize(elements = [], order = -1)
    @elements = elements
    @compare = lambda { |left_el, right_el| (left_el <=> right_el) == order}
  end

  def size
    @elements.size
  end
end

E aqui é onde o spaceship operator entra em ação. A lambda utilizando o order com 1 negativo quer dizer que sempre que compararmos um valor menor com um maior, retornará true. Isso nos garante que ao compararmos o elemento com um pai por exemplo, ele vai retornar true caso precise trocar

Enfileirando...

Ao enfileirar um elemento na Priority Queue, veremos se é necessário o processo de bubble up. A vantagem de traduzirmos a árvore binária para um array é que conseguimos computar facilmente o parente daquele elemento inserido. Existe a fórmula pronta pra conseguir o index do parente, do filho da esquerda e da direita. No caso de enfileiras vamos usar só a fórmula do parente.

PARENT = (TARGET_EL_INDEX - 1) / 2

  def <<(element)
    # Insert new element into array
    @elements << element

    # Get the inserted element index
    target_index = size - 1

    # Get the parent from the inserted index
    parent_index = (target_index - 1) / 2

    # Here, we use compare lambda to make sure we always swap the parent with the inserted element, to respect the min heap property (The child priority must be greater than parent's priority)
    while @compare.call(@elements[target_index], @elements[parent_index])
      # parent greater than child? swap it
      swap(target_index, parent_index)

      # update the respective indexes if next @compare.call succeeds
      target_index = parent_index

      parent_index = (target_index - 1) / 2
    end
  end

Nota-se que a order da PriorityQueue vai seguir a padrão (-1), ou seja, uma Min Heap.

Pop, pop, pop

Para o processo de bubble down, vamos usar as duas fórmulas pra encontrar o filho da esquerda e o filho da direita do elemento que precisa descer na árvore.

LEFT_CHILD = 2 * (TARGET_EL_INDEX) + 1
RIGHT_CHILD = 2 * (TARGET_EL_INDEX) + 2

  def pop
    # swap the binary tree root with the last element
    swap(0, size - 1)

    # remove last element from queue
    @elements.pop

    # computations to reach the left/right child
    target_index = 0
    left_index = 2 * target_index + 1
    right_index = 2 * target_index + 2

    # here we start the bubbling up procedure and we dont stop until our childs elements is greater than its parents
    while (left_index < size && @compare.call(@elements[left_index], @elements[target_index])) || (right_index < @elements.size && @compare.call(@elements[right_index], @elements[target_index]))
      # if right and left child holds the same priority, then we use the data contained into it to decide which is smaller
      smallest_index = if right_index >= size || @elements[left_index].data < @elements[right_index].data
                         left_index
                       else
                         right_index
                       end

      # we swap it boooyyy
      swap(target_index, smallest_index)

      # update indexes in case this was not the last swap we needed it
      target_index = smallest_index
      left_index = 2 * target_index + 1
      right_index = 2 * target_index + 2
    end
  end

Amostras & conclusões

Vamos lá...
Criei um método inspect dentro da class PriorityQueue pra ficar fácil o debugging.

  def inspect
    res = []
    for el in @elements
      res.push(el.data)
    end

    res
  end

E voilà:

irb >>
min_heap = []

min_heap << Element.new(4)
min_heap << Element.new(8)
min_heap << Element.new(6)
min_heap << Element.new(9)
min_heap << Element.new(12)
min_heap << Element.new(7)
min_heap << Element.new(10)

pq = PriorityQueue.new(min_heap)
p pq.inspect()
=> [4, 8, 6, 9, 12, 7, 10]

pq << Element.new(5)
p pq.inspect()
=> [4, 5, 6, 8, 12, 7, 10, 9]

pq.pop()
p pq.inspect()
=> [5, 8, 6, 9, 12, 7, 10]

pq.pop()
p pq.inspect()
=> [6, 8, 7, 9, 12, 10]

pq.pop()
pq.pop()
pq.pop()
p pq.inspect()
=> [9, 12, 10]

Na stream procurei fazer os testes e esse debugging usando excalidraw pra facilitar o entendimento dos resultados.

Pretendo melhorar esse código, colocar novos métodos (por exemplo um pop que tem index como argumento). Se te interessar, pode ficar ligado no meu github e nas streams. Até mais ver. o/

É necessário voltar ao começo

Yury Cavalcante — Wed, 03 Apr 2024 15:22:53 +0000

"[...] Que é necessário voltar ao começo
Quando os caminhos se confundem, é necessário voltar ao começo
Não sabe pra onde ir? Tem que voltar pro começo
Pra não perder o rumo, não pode esquecer do começo
Cê entende, que assim é verdadeiro? ...

Apresentando

Olá, espero que encontre esse texto num momento bom da sua vida. Sente-se comigo e vamos lá.

Este é um post de contexto tech, mas eu tenho alguns adendos antes de prosseguir a parte técnica dele. Faz uma semana que me encontro desempregado e nos primeiros dias tive pensamentos suicidas algumas vezes. Pra pessoas próximas que acabaram tropeçando nisso aqui e continuam lendo: eu estou bem agora! Não se preocupem. O motivo (por inteiro) não foi o desemprego.

Me encontrei sem significado em existir, e percebi que fui muito perverso em resumir minha existência no profissional, e desde então decidi recomeçar tudo. Quero encontrar o brilho nos meus olhos na área novamente e acho que, se você que é de tecnologia e já questionou muitas vezes seu existir talvez seja interessante continuar aqui.

Não pretendo ser prepotente, é uma escrita em forma de desabafo com uma continuidade em aprendizado. Então vamos lá.

Prazer, Yury, vou estar estudando o que considero de faltante em minha carreira e vou compartilhar nos posts a seguir. Esse é o primeiro deles. Pensei em muitos projetos mirabolantes a serem feitos mas decidi por estudar ESTRUTURA DE DADOS e ALGORITMOS. Simplesmente porque sempre admirei pessoas que tinham essa base forte e bem enraizada. E eu quero me tornar uma dessas pessoas. Me admiro por muitos outros pontos e acho que esse deverá ser um deles no futuro!

Aprendendo a andar novamente

Após meditar muito sobre o que fazer nos próximos dias, eu iniciei o estudo e ao mesmo tempo parei de utilizar VSCode como editor de código. Sempre tive vontade de adquirir eficiência e velocidade durante minhas sessões de coding e optei por Doom Emacs.

Estive consumindo conteúdo sobre estrutura de dados, algoritmos,
programação competitiva e leetcodes. Acho que é a base que me falta. Tenho boas ideias de negócio e de system design, mas eu não consigo discutir os pormenores dessas implementações por falta de jargão e experiência em algoritmos. Então nessa primeira semana eu implementei em Ruby, algumas estruturas de dados tanto abstratas quanto concretas.

Esse é o pontapé inicial dos textos semanais que quero fazer sobre o meu tempo desempregado e o que estarei aprendendo, os próximos terão mais discussões técnicas e decisões que tenho tomado em relação a elas.

Até mais ver

Agradeço primeiramente a mim por ter considerado escrever isso, e segundamente a todos que estão estimando pelo meu bem nessa caminhada.

Os estudos dessa semana me fizeram me sentir muito bem, já sinto estar entendendo as coisas melhor, mesmo em pequena porcentagem. Então, se você se identificou minimamente até aqui, te digo: de vez em quando é necessário voltar ao começo, independente da onde estiver.

E por último, não menos importante, para todos ao meu redor que zelam por mim: Vocês me movem. É o grande motivo d’eu estar escrevendo isso aqui e me reerguendo.