In partnership with
How Jennifer Aniston’s LolaVie brand grew sales 40% with CTV ads
For its first CTV campaign, Jennifer Aniston’s DTC haircare brand LolaVie had a few non-negotiables. The campaign had to be simple. It had to demonstrate measurable impact. And it had to be full-funnel.
LolaVie used Roku Ads Manager to test and optimize creatives — reaching millions of potential customers at all stages of their purchase journeys. Roku Ads Manager helped the brand convey LolaVie’s playful voice while helping drive omnichannel sales across both ecommerce and retail touchpoints.
The campaign included an Action Ad overlay that let viewers shop directly from their TVs by clicking OK on their Roku remote. This guided them to the website to buy LolaVie products.
Discover how Roku Ads Manager helped LolaVie drive big sales and customer growth with self-serve TV ads.
The DTC beauty category is crowded. To break through, Jennifer Aniston’s brand LolaVie, worked with Roku Ads Manager to easily set up, test, and optimize CTV ad creatives. The campaign helped drive a big lift in sales and customer growth, helping LolaVie break through in the crowded beauty category.
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: an alert that didn't say anything was down — it said checkout success was down 40%. Every service was healthy. The rate limiter we'd shipped a week earlier was working exactly as designed: 100 requests/minute per user, way more than any real user should need. Except a slow network meant legitimate checkout retries could burn 5-10 requests in under a minute, and real, paying customers started getting blocked at the exact moment we least wanted to say no to them.
The article covers what we changed. What I want to add here is the follow-up question I'd ask you about this in an interview, since "pick an algorithm" is the easy 80% of a rate-limiting answer.
The question that actually separates people
Almost every candidate can name token bucket, sliding window, fixed window, and explain the mechanical difference between them. That's table stakes. The question I actually care about is:
"Where did your number come from, and did you validate it against your worst-case legitimate user — not your average one?"
Weak answers treat the limit as an engineering constant, picked from a spreadsheet estimate of "normal" traffic. Strong answers recognize that the limit is a business decision wearing an engineering costume — it encodes an assumption about real-world behavior (retries, flaky connections, shared IPs) that has to be validated against the messiest real client, not the cleanest one.
The follow-up that goes even further: "Do you rate-limit intent, or just identity?" A payment confirmation retry and a casual browsing request from the same user aren't the same kind of traffic, and treating them identically is exactly the mistake in this week's story. Candidates who bring this up unprompted are telling you they've actually lived with a rate limiter in production, not just implemented one on a whiteboard.
Why this generalizes
This isn't really a rate-limiting-specific lesson. Any protective mechanism — rate limits, circuit breakers, timeouts, retry budgets — is only as good as the model of real traffic it was built against. The algorithm is rarely where these systems fail. The assumption baked into the number is.
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.
Ever had a protective system quietly hurt real users while working exactly as designed? Hit reply — I read everything.
Talk soon, Vrinda