po, baita pergunta essa, vou formalizar como se estivesse respondendo pra um recruiter:

Com certeza o maior desafio que precisei resolver foi a remodelagem de uma das tabelas principais do core da aplicação, pra melhorar a performance e adequar com uma nova regra de negócio que havia sido validada com o cliente.
Essa tabela (A) reunia informações sensíveis, dentro da aplicação, de cada usuário, haviam diversos "JOINs" para poder condensar tudo e retornar ao front um "extrato" dos dados que o usuário precisava ver.

A complexidade dessa funcionalidade começou quando algumas validações de data e outros campos opcionais que o usuário poderia ter surgiram, assim como, um tipo de perfil específico do qual o usuário pertencia, junto com a possibilidade de "acumular" saldos totais de contas diferentes mas com o mesmo "tipo-de-conta". Porém, na nossa modelagem inicial o perfil do usuário não estava presente em nenhuma das tabelas onde a tabela A consultava para montar o "extrato", então, adicionamos esse campo na tabela A e seguimos o desenvolvimento.

E o desafio ficou ainda maior quando vimos que após alguns testes de carga realizados pela equipe de CS junto com os QAs os "JOINs" estavam detonando a performance fazendo com que estourasse o tempo de execução da função na AWS (Lambda), como cada usuário poderia ter facilmente mais de 5 contas, com mais de centenas de registros em cada, o número de itens por conta por usuário começou a gerar um gargalo. E ai começamos um trabalho extenso de remodelagem de cada tabela relacionada à esse processo (e posteriormente todas as tabelas da aplicação), por se tratar de um banco não-relacional optei por replicar dados da tabela X na tabela A afim de evitar JOINs (ou populates) e também melhoria na lógica de aplicação de filtros para tornar as queries mais eficientes, estudos sobre algorítmo e ED pra ajudar a identificar formas de melhorar processos de inserção e atualização entre outras medidas que foram tomadas. No fim conseguimos reduzir em 20s o processamento dos usuários de teste com dados em grande quantidade oque nos deu segurança de saber que não teríamos timeout no serverless nem em processos de atualização do banco.

Esse problema foi identificado primeiramente pelo meu PO na época e depois levado a testes pela equipe de CS junto aos QAs, e ja que se tratava de uma atividade que eu havia desenvolvido do 0 e já estava entregue, fui o responsável por adequar as queries e a lógica de inserção/atualização junto às melhorias necessárias nas models que esse processo utilizava. Mas como se tratava de um problema que iria impactar em outras partes do produto, nosso tech-lead e o CTO elaboraram um projeto de remodelagem para todo o software onde delegaram as tarefas para os responsáveis ou quem possuía maior conhecimento em partes específicas, tudo aconteceu em paralelo então eu diria que ajudei a identificar o problema a gestão das equipes comunicou oque eu deveria fazer.