In partnership with
7 External Traffic Strategies. One question finally answered.
What actually moved your BSR?
Most eCommerce brands running external traffic can't answer that. Wrong channels, no real attribution, and at the end of the month, a dashboard full of activity and no proof of what drove revenue.
The brands getting it right aren't spending more. They've just stopped guessing.
They know which channels pull weight on Amazon listings, which ones look good in a report but bleed budget, and why creator and affiliate traffic consistently outperform paid social when it's set up correctly.
Levanta's free playbook breaks down all 7 strategies. Where each one works, where it falls apart, and what it takes to scale without it becoming a second job. If you're serious about moving your BSR without living inside PPC, this is worth 5 minutes.
Hey — welcome back to The 2AM Postmortem.
If you're new here: I'm Vrinda, an SDE2 at Salesforce, previously at Amazon and Walmart. Every week, one real backend incident or design decision, no textbook theory.
Quick recap, if you haven't read it yet
This week's Medium piece: a document-editing feature with an AI assistant bolted on. Edit a paragraph, ask the assistant about it — except a user asked immediately after editing and got an answer based on the old version. Not a hallucination, not a prompt bug. The embedding pipeline simply hadn't caught up yet. The vector store was just another replica in an eventual-consistency system, wearing an AI costume.
The article covers where the lag actually lived and what fixed it. What I want to add here is the follow-up questions I'd actually ask you about this in an interview — the ones that separate "I understand RAG" from "I've had to debug one."
The 3 follow-ups I'd ask after you explain this bug
1. "How long is the actual gap between a write and that data being queryable — and how do you know?" Most candidates guess. The strong answer is "I measured it under real load," because the gap under a quiet afternoon and the gap during real traffic are often wildly different numbers, and only one of them matters.
2. "Does your system know when its own answer might be stale, or does it just answer regardless?" This is the question that exposes whether someone has actually thought about failure, or just about the happy path. A system that can say "still processing your latest edit" is doing something meaningfully harder than one that just always answers confidently.
3. "Is this an embedding-pipeline problem, or a UX problem?" The strongest candidates recognize that sometimes the "fix" isn't technical at all — it's telling the user the truth about what's happening, instead of engineering away every trace of lag. Knowing when to solve a staleness problem with an interface instead of an algorithm is a senior-level instinct.
Why this one's worth sitting with
A RAG pipeline is a distributed system with a language model stapled onto the end of it — it inherits replication lag, stale reads, and race conditions same as any database-backed system.
The dangerous difference: a database returning stale data usually looks stale (an old timestamp, a visibly outdated field). A language model returning stale data looks exactly as confident and fluent as one returning correct data. That's what makes this failure mode worth specifically training yourself to look for.
Before you go:
If you're prepping for system design interviews, I put together a free cheat sheet — the questions I actually ask candidates, and what separates a pass answer from a fail one. Download it here.
Hit a staleness bug that looked like something else entirely at first? Hit reply — I read everything.
Talk soon, Vrinda