</> 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 5: Where a Swipe Lands - Data Modeling

Executive Summary: Priya's right swipe on Marco writes two rows, reads one, and, because Marco liked her on Thursday, writes three more. This section derives where each row lives from the questions the system asks its data. Profiles sit in a sharded relational store. Swipes, the reverse likes index, matches, messages and blocks live in Cassandra, each partitioned by the key its hottest read needs. Redis and Elasticsearch hold only derived, rebuildable state. The decisions to defend are the 90-day TTL on swipes, the likes_received table that turns "did Marco like Priya?" into a point read, and the blocks table that never expires.

The interviewer points at Section 4's endpoint list: "Fine. What do these calls actually write?" Don't open with tables. Open with the questions, how often they're asked, and the key each one needs, because in a wide-column store the key is the query.

Access Patterns First

Access pattern Peak rate Key it needs Home
Record a swipe ~70K rows/s swiper, then swipee Cassandra swipes
Did they already like me? (match check) ~21K reads/s me (the swipee), then them Cassandra likes_received
Create the match, exactly once ~700/s the sorted pair Cassandra matches
My matches list, newest first low user, by time Cassandra matches_by_user
Chat history for one match ~3.5K writes/s match, by time Cassandra messages
Is this pair blocked? every send, every deck user, then other Cassandra blocks
My next 20 cards ~3.5K fetches/s user Redis deck: queue
Have I seen this candidate? ~1.4M checks/s, local user Redis Bloom filter
Who is near me and fits both ways? ~1.4K refills/s S2 cell + filters Elasticsearch geo index
Hydrate a card (name, age, photos) per card served user Profile DB + CDN

Access patterns first: questions about likes, swipes, matches and chat, and blocks go to Cassandra; next cards and have-I-seen-them go to Redis; who is near goes to the Elasticsearch geo index; profile cards come from the profile DB and blob storage

Cassandra and the profile DB are systems of record. Redis and Elasticsearch are derived: lose them and you rebuild.

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.