Bruno Matuk Long

Bruno Matuk LongJul 22, 2026

In 2019 I led the rebuild of a shopping cart system that couldn't go down, not even for an hour, because it was the thing standing between browsing and paying. I had opinions about the new stack. Strong ones. But I didn't make a single one of the big calls alone. Every technology decision went through the team first. Not as a formality, as an actual filter. Twice, someone pushed back on a choice I'd already half-committed to in my head, and both times they were right. One of those pushbacks is the reason we don't have a piece of tech debt right now that I would've happily signed up for six months ago. The idea that actually saved us, though, wasn't a technology choice at all. It was splitting the whole rebuild into phases, and building each phase to work backward with what already existed. Old cart, new cart, running side by side, every step of the way. Nobody had to choose between "ship the new thing" and "keep checkout working." Both, always, at the same time. It's slower. It's also the only version of this project where a mistake in phase three doesn't take down what phases one and two already got right. What's a decision you made better by bringing in someone who disagreed with you?

Bruno Matuk LongMay 20, 2025

Sim, estamos vendendo passagens de ônibus dentro do app da moovit 💪🤓 Com essa nova parceria, os usuários do Moovit encontrarão uma quarta aba na tela inicial do aplicativo, denominada “Bilhetes” . A partir dela, é possível selecionar origem, destino e dados de viagem, acessar múltiplas opções de rotas e adquirir bilhetes de diversas empresas de ônibus consolidadas em todo o Brasil, que são integrados ao DeÔnibus

Bruno Matuk LongJul 2, 2026

Four years into this and I still got the order wrong on a mock interview last week. Question: a downstream service is flaky. Payment processor, doesn't matter which. What do you check first. I said retries. Wrong answer, and I've shipped enough AWS SQS consumers that I should've known better. Here's the order that actually holds up, in this sequence, not randomly: 1. Timeout. Fail fast. Skip this and every other fix just compounds the outage, because requests pile up behind an unbounded wait. 2. Retries, with exponential backoff and jitter. Not 3 retries in a tight loop. That's just you DDoSing your own dependency. 3. Circuit breaker. After N failures in a window, stop calling entirely and fail immediately. Give the service room to actually recover. 4. Fallback. Cached value, degraded response, queue it for later. Anything except a spinning loader. I had 3 and 4 flipped in my head for years. Fallback felt more "senior" to mention first, so I led with it. Backwards. If you fall back before you've stopped hammering a dying service, you're still adding load to something on fire. Curious how other people order this. Anyone here put circuit breaker before retries?