12 tópicos que a Samara já cobrou

Regra das 3 dicas dela

1. Ruby/Rails na prática — zero definição de livro.
2. Exemplo de projeto real (iugu, Bling, Zaitt, Cão Cidadão).
3. Por que essa estrutura para essa regra de negócio.

Frase-molde: “No X eu fiz Y porque Z. Se fosse de novo, faria W.”

1 · Ruby na prática

Na call: calculadora. Troca por regra de dinheiro.

Ruby brilha em objeto pequeno com regra, bloco e Enumerable — não em “é interpretada e tem duck typing”.

class Discount
  def initialize(percent)
    @percent = percent
  end

  def apply(amount_cents)
    amount_cents - (amount_cents * @percent / 100)
  end
end

# no pedido:
line_totals.map { |cents| discount.apply(cents) }.sum

2 · Cadastro de clientes no Rails

Na call: scaffold. Scaffold é gerador, não a estrutura.

• db/migrate — tabela clients (name, document, email)
• app/models/client.rb — validates :name, :email; uniqueness
• config/routes.rb — resources :clients
• ClientsController — index/show/create/update; client_params
• Se a regra cresce: Clients::Create service, não 80 linhas no create

# routes
resources :clients

# controller
def create
  @client = Client.new(client_params)
  if @client.save
    redirect_to @client
  else
    render :new, status: :unprocessable_entity
  end
end

private
def client_params
  params.require(:client).permit(:name, :email, :document)
end

3 · API REST + Git

Na call: git init. Git de time é branch + PR.

• rails new app --api se for só JSON
• namespace :v1 { resources :clients } → GET/POST/PATCH/DELETE
• Auth: token (Doorkeeper / API key) — outro sistema não entra aberto
• Git: branch feat/clients-api, commits pequenos, PR, review, squash/merge, tag de release

4 · Case grande — iugu, não só a loja

Na Samara você foi de ERP + Bling (bom). No cliente, abre com iugu.

Bling entra como “integração com rate limit → Redis/Sidekiq → GoodJob+Postgres porque era app só meu”.

5 · O que testar + feature antiga

• Sempre: model / PORO da regra (desconto, status, duplicidade).
• Quase sempre: request spec do create/update (contrato HTTP).
• Pouco: e2e da tela inteira.
• Legado com muitos users: não faxina. Teste de regressão no caminho feliz, feature flag se der, entrega no desenho que já existe.

6 · Serviço de pagamento lento / fora

Termos que faltaram: timeout, retry, circuit breaker, fila, idempotência.

1. Request do user não espera o gateway 30s → job Sidekiq.
2. HTTP client com timeout curto (3–5s).
3. Retry com backoff só em 5xx/timeout — nunca em 4xx.
4. Circuit breaker: se o provedor cai, para de martelar.
5. Idempotência (chave do pagamento) para não cobrir 2×.
6. UI: “processando”; webhook confirma.

7 · Tela lenta — ela perguntou banco

Paginação sozinha não responde “está no DB?”.

1. Log ActiveRecord / Skylight / rack-mini-profiler: tempo SQL vs Ruby.
2. N+1: includes(:orders) — cada cliente disparando pedido.
3. EXPLAIN ANALYZE no SELECT pesado.
4. Índice em client_id, created_at, o filtro da tela.
5. Paginação no SQL (limit/offset ou keyset), não filtrar array em memória.

8 · 5× usuários — antes de subir servidor

• O que é síncrono e pode ser fila (e-mail, PDF, sync Bling).
• Queries e N+1 (item 7).
• Cache (Redis) em leitura quente.
• Connection pool do Postgres vs puma workers.
• CPU vs IO vs DB — sobe web só se for CPU. Se for DB, replica de leitura ou índice.

9 · Controller gordo

Você já falou services. Fecha com exemplo.

Nomes: service object, form object, query object, job. Não precisa citar os quatro. Um basta.

10 · Muitas transações · DB no limite

O termo que faltou: lock (pessimista / otimista), connection pool, backpressure.

• Ver se o gargalo é lock de linha, pool esgotado ou query lenta.
• Pessimista: lock / FOR UPDATE em saldo — serializa na linha.
• Otimista: coluna lock_version — dois updates, um falha, retry.
• Fila na frente do DB (Sidekiq) = backpressure: o HTTP não abre 2 mil transações juntas.
• Read replica se for leitura. Não replica escrita.

11 · Microsserviços no legado

12 · Review + primeiros dias

Review com dívida futura

Primeiros dias (legado + feature urgente + perf + 2 APIs, time pequeno)

1. Dia 1: sobe o app, lê README, quem é dono das 2 APIs, onde está o p95.
2. Fatia a feature no menor caminho que gera valor.
3. Se a feature passa pelo gargalo de perf, trata esse risco. O resto do legado espera.

Inglês — 40 segundos cada

Ensaiar em voz alta. Devagar. Pedir para repetir a pergunta é ok uma vez.

Tell me about yourself

How would you structure clients in Rails?

REST API and Git?