Section 11: Growth Without Demolition - Follow-up Feature Evolution
Executive Summary: The interviewer reads out the monetization roadmap to see whether the design bends or breaks. For seven features we name the seam each one plugs into, the one new piece it needs, and the trap inside it. Two decisions bend on purpose: D14 gets two deliberate, paid exceptions (Super Like and Likes You), and Passport is the first feature that pushes on D12's flip trigger. The swipe store, the write-then-check match, and the precomputed deck survive all seven.
The interviewer turns the page: "It shipped and people love it. Now the business wants revenue. Here's next year's list. How does each one land, and what do you tear down?"
"Before the list, here are the seams I'll check each feature against. One, the swipe store:
swipesandlikes_received, 90-day TTL. Two, the refill pipeline: ranking plus the attention budget. Three, the geosharded index. Four, D14: the server holds the secret of who liked whom. Five, chat authorization: match active, no block. A feature that lands on one of these is cheap. A feature that needs a sixth seam is expensive, and I'll say so."
Key Insight: Every paid feature here sells something the free design already computes and deliberately withholds or rations: who liked you, where you rank, which city you're in. That makes evolution cheap to build and dangerous to get wrong, because each feature is a controlled leak of a secret Section 10 worked to keep.
1. Super Like
A Super Like is a like the recipient is meant to see. The contract barely moves: PUT /v1/swipes/{target_id} with {"direction": "superlike"}. The swipe service stores it as a like with super = true in both swipes and likes_received, so Section 7's write-then-check and the deterministic match_id run unchanged.
What's new is delivery. The recipient's deck was precomputed hours ago, so a superlike event on Kafka tells the deck service to insert the sender near the front of deck:{recipient}. The card then carries super_liked_you: true. That is D14's first deliberate exception: the sender paid to reveal this one like.
The trap: the insert skips the refill pipeline, so it must re-run its checks (reciprocal fit, no block, not in the recipient's seen-set), or a paid feature becomes a way to reach someone who blocked you. The daily quota is enforced server-side, and because the PUT is idempotent, a retry on a flaky connection doesn't spend two.
Quick check before moving on:
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson