</> MAANG.io
system design · 301

Advanced

Master system design interviews with scalable architecture patterns, distributed systems, and real-world design challenges.

0/480 solved 0% complete

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: swipes and likes_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."

Each follow-up feature maps onto an existing subsystem: Super Like, Rewind and Likes You on the swipe store, Super Like and Likes You on D14, Boost and Photo verification on refill ranking, Passport on the geosharded index, Video chat on chat authorization

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

Sign in to MAANG.io

Use your Google or Microsoft account — no password to remember.

Continue with Google Continue with Microsoft

Please accept the terms above to continue.