Junior to Staff at Meta in 3 years. That sentence raises eyebrows.

I’ve dodged telling this story for years. Maybe it’s the ex-athlete in me cringing at self-promotion, or maybe I’m just uncomfortable with attention I’m not sure I deserve. But after countless requests to share it, I figured it’s worth putting out there — even if it makes me squirm.

Let’s start with the reality check: I hit the timing jackpot. Right org, explosive growth phase, and a manager who saw something in me before I saw it myself. If you’re looking for a pure meritocratic story, this isn’t it. Nobody lands promotions this fast without the stars aligning.

Still, there were patterns and principles that emerged — insights that might be useful to others on their own paths.

Looking back, six key principles had the largest effect on my career.

First principle: Speed is your multiplier. Everyone talks about thinking bigger or making an impact, but none of that matters if you can’t nail your core work faster than others. When you can complete your normal workload with 70% of your time, that extra 30% becomes your secret weapon. That’s where the real growth happens.

The second principle relies on the first: Keep your head up and your aperture wide. Use that extra bandwidth to operate like someone a level above you. As a junior dev, I studied what my teammates were doing, connecting dots they might have missed. At senior, I expanded that lens to sister teams. By Staff, I was thinking across entire organizations.

Here’s the third thing, and it’s a liberating truth: No one has all the answers. Not your boss, not the VPs, not even the CEO. This isn’t meant to dismiss their expertise — I’ve learned invaluable lessons from every leader I’ve worked with. But realizing this freed me to put my ideas out there without the paralyzing weight of needing to be right.

The fourth principle grounds everything else: focus on problems, not technologies. You don’t need to be the most technical, brilliant person in the room. What matters is seeing the simplest path to the goal. While others might get caught up in building elegant technical solutions, I learned that stepping back and questioning our basic assumptions often revealed much more simple solutions hiding in plain sight.

Fifth: Build goodwill early and often. Remember that extra 30% of time you got back? Use it to help others. Support your cross functional partners, lend a hand to other engineers, and jump in when other functions need backup. These deposits in the “favor bank” compound over time.

Finally — and this might be the most underrated factor — stay positive. Our industry can be surprisingly cynical. But look around: We’re solving fascinating problems, working with brilliant people, and yes, being well compensated for it. A positive outlook isn’t just about being nice — it’s a career accelerant.

1. Speed Is Your Multiplier

This first principle might be the hardest one to replicate, but it’s a necessary foundation.

From day one at Meta, I could grasp problems and crank out code faster than most people around me. Maybe it was luck, maybe it was my background — I’m not sure.

My first project at Meta involved migrating a legacy system that ingested ISIS and Al-Qaeda propaganda content and then hashed it to prevent copies from appearing on the platform. The timeline was set for “a month plus.”

I finished it in under a week.

I now had three weeks to make it better. I redesigned the entire system. We took ingestion times from multiple days down to just seconds. And timing was critical here.

When terror organizations post new media, their followers immediately reshare it across platforms. Most views happen within the first few hours. Our original pipeline, taking days to process, meant we were always too late. By reducing ingestion time to seconds, we could catch and block content before it gained traction.

This was real, significant impact in my first month on the job as a junior engineer. We were now detecting an order of magnitude more harmful content.

If you’re not yet blazing through your core responsibilities, stop reading this article. Put all your energy into mastering your fundamental skills first. That speed multiplier — that extra 30% of time when you’re good at your core job — unlocks everything else we’re about to discuss.

2. Operating Above Your Level

Freeing up 30% of your time changes everything. You can use it to develop the perspective of someone a level above you. This mindset came naturally when I was a junior engineer, but as I grew more senior, I needed my manager to push me to think even bigger.

As a junior engineer, I wasn’t just focused on my tasks — I was studying how my senior teammates approached problems, evaluated trade-offs, and thought about systems. By the time I hit senior, I had shifted my lens to understanding how staff engineers connected broader technical strategies across teams. And as I approached staff, I was thinking about how technical decisions impacted entire organizations and shaped our long-term architecture.

This pattern of looking ahead served me throughout my career. Each step up wasn’t just about doing more — it was about seeing more. Understanding the concerns, constraints, and opportunities that only become visible at higher levels.

It’s easy to get stuck with a narrow aperture. Widening it is uncomfortable — you’re stretching your mind to consider problems you’re not yet expected to solve. I leaned heavily on my manager and trusted senior engineers to understand how they thought about problems at their level, then worked to develop that same perspective.

The beauty of this approach is its simplicity. At worst, you develop a deeper understanding of your organization’s challenges. At best, you start operating at that next level, making promotion a recognition of how you already think rather than a bet on your potential.

3. No One Has All The Answers

Many engineers join FAANG companies with crippling impostor syndrome. That alone is enough to sink — or at least significantly stall — most careers.

For whatever reason, I didn’t have it. Seeing the vulnerability of others around me reinforced a powerful truth — no one has all the answers. Not the senior engineers, not the directors, not even the VPs. Once I internalized this, I was suddenly free to share ideas broadly and without hesitation.

Meta was a unique place for this mindset. Workplace, our internal version of Slack, allows employees to share their work and ideas across the company. This effectively surfaced valuable insights, regardless of an employee’s level. You could develop a concept, draft a proposal, or pose a thought-provoking question and post it for everyone to see. The most impactful contributions naturally rose to the top.

Sometimes, my posts got no reaction. Sometimes, that reaction was even negative. For example, I remember one post where a veteran employee publicly stated all the reasons why my proposal was idiotic. But here’s what mattered: nobody remembered or cared the next day, including me.

Other times, my posts went viral and led to meetings with directors or VPs to discuss my ideas 1:1. It was meritocracy at its finest — but you could only take advantage of it if you weren’t paralyzed by the fear of looking stupid. Once you accept that, you stop waiting for permission to contribute.

4. Simple Solutions to Complex Problems

There’s a tendency in tech — especially at companies like Meta — to reach for complex technical solutions. We’re surrounded by brilliant minds building cutting-edge technology, so it’s easy to get caught up in that current. But I learned early on that my strength wasn’t in being the most technically sophisticated engineer in the room. Instead, it was in seeing the clearest path to solving the actual problem.

A perfect example of this came during my work on suicide prevention. Our team faced an incredibly difficult challenge: detecting potential suicides in live videos in real time. The stakes couldn’t have been higher — every false negative meant a potentially missed opportunity to save a life.

We had a team of brilliant ML PhDs working alongside Meta’s unified AI org to develop state-of-the-art models for video and audio. The technical complexity was staggering. But after watching enough false negatives, I noticed something that seemed almost too obvious. While our sophisticated models were still processing frame sequences and temporal features, the viewers in the comments section had already identified the crisis.

Comments like “don’t do it” or “it’s not worth it” were appearing consistently. While we were pouring resources into optimizing frame embeddings and acoustic models, the clearest signals were hiding in plain sight.

I suggested we add comments as a modality to our model. The results were immediate and dramatic: our recall jumped from 9% to over 50%. This breakthrough gave us a foundation to build on, and with further iterations — including incorporating comment embeddings as temporal features in our sequence models — and an expanding training dataset, we pushed our recall into the 90% range.

This experience reinforced a crucial lesson: sometimes the best solution isn’t the most technically sophisticated one. Taking a step back, questioning our assumptions, and being willing to see the problem from different angles does wonders. I’ve followed this principle throughout my career — always pushing myself to grow technically, but never letting the pursuit of technical elegance overshadow the fundamental goal: solving the problem.

5. The Favor Economy

Conventional wisdom says don’t get distracted by things that don’t drive direct impact. That’s good advice for what it’s worth, and it’s absolutely true in the startup world.

But I took a different path, and it paid off.

I helped everyone, especially in the beginning. Whether it was ops, DE, DS, or other engineers — it didn’t matter if they were higher or lower level — I went out of my way to help.

There’s a fine line here, which I struggled with as I grew more senior. Time is finite and valuable. You can’t waste it.

But those early favors compound. By the time I hit Staff, others I’d helped had grown too. That manager from another team I helped? Now a director. That ops guy I assisted? Director of ops. While I never expected favors in return, they trusted me. That goodwill meant I was in all the right conversations. People came to me first with their ideas and opportunities.

If someone outside the org wanted to talk about Content Integrity (my org), there was a good chance my name came up and they were routed to me. Those cross-discipline relationships I built meant people associated my name with my organization. And now those people were in positions of power. Say what you want about whether this is good for an organization, but it was definitely good for my career.

6. The Power of Positive Motion

I saved this one for last because it’s both the easiest to replicate and the most underappreciated. The tech industry breeds cynicism. You’ll find countless LinkedIn posts complaining about how big companies exploit their workers. Yet where else can you earn $200k+ straight out of college, enjoy free meals, excellent benefits, and a healthy work-life balance? We solve fascinating problems alongside brilliant minds while being well compensated. That hardly qualifies as exploitation in my book.

Instead, I chose a different path: I made a conscious decision to never talk shit about anyone — not even in my thoughts. This wasn’t about ignoring problems. I saw the flaws and felt the frustrations just like everyone else. But unless I could meaningfully address an issue, I wouldn’t focus on it.

This mindset shift changed everything. I genuinely looked forward to coming to work each day. I found myself excited by our challenges rather than drained by them. I fully bought into our mission. Most importantly, I discovered that work became more fun — and there’s no limit to what you can accomplish when you’re enjoying what you do.

Happiness and positivity are wild accelerants in life, not just work.

Conclusion

The reality is there’s no magic formula for rapid career growth. My path was as much about fortunate timing as deliberate action. But while we can’t control timing, we can control our approach.

These six principles — mastering speed as a multiplier, operating above your level, embracing that no one has all the answers, focusing on simple solutions to complex problems, building a favor economy, and maintaining positivity — weren’t strategies I consciously developed. They emerged naturally as I reflected on what worked. They’re not prescriptive steps to follow, but rather patterns I noticed in retrospect.

Here’s what I know for certain: if you’re reading this looking for a blueprint to replicate my timeline, you’re focusing on the wrong thing. The timeline isn’t what matters. What matters is building sustainable habits that compound over time. Start with mastering your core responsibilities. Use that mastery to create bandwidth. Deploy that bandwidth strategically. Build relationships. Stay positive. The rest will follow.

Good luck.

I saw it every weekend while living in Seattle: software engineers making half a million dollars arguing over dinner bills down to the cent, cramming into someone’s car to save $5 on an Uber, and pre-gaming at home to avoid $15 cocktails. All while making more money than we knew what to do with.

It took moving to LA to realize just how weird this behavior is. Here, I’ve made friends outside the tech bubble — people making significantly less than my Seattle circle, yet somehow living much richer lives. They grab the check without hesitation. Spring for concert tickets on a whim. Generally seem to enjoy their money rather than hoarding it like dragons guarding their gold.

The contrast was jarring. In Seattle, we’d spend hours fine-tuning our investment strategies and debating the optimal savings rate. Every dollar spent was a dollar that could be invested, and we could calculate exactly how much we expected that dollar would be worth in 30 years. The engineer’s mindset applied to lifestyle choices — and it was making us miserable.

I get it. We’re analytical by nature. Tech attracts people who love watching numbers go up and to the right. But we’re optimizing for the wrong variable.

The proof is right there on Blind. Some of the unhappiest posts come from people making $1M/y who are stressed about not saving enough. They’ve solved the money problem but lost sight of the happiness equation.

Arthur Brooks, a Harvard professor who studies the science of happiness, was asked a simple question: does money buy happiness? His answer was surprising. “Yes,” he said. But it came with a crucial caveat: “yes, if that money is spent on experiences with the people you love.” On the other hand, he found those hoarding money, regardless of how wealthy they were, were almost always the least happy.

Here’s what I’ve learned since leaving the tech bubble: investing in experiences yields better returns than obsessing over savings. And I mean that literally — the compound interest of strong relationships and shared memories pays dividends far beyond what your optimization efforts will ever yield. The best retirement plan includes both financial security and people who actually want to spend time with you.

This isn’t about being reckless. Save for retirement. Build your emergency fund. But once those bases are covered (and let’s be honest, in tech, they usually are), stop treating every dollar like it needs to be optimized. That $200 dinner won’t appreciate like an index fund, but the relationships you build might be the best investment you’ll ever make.

Life’s too short to be the richest person in the retirement home.

Understanding the Problem

🖱️ What is an Ad Click Aggregator An Ad Click Aggregator is a system that collects and aggregates data on ad clicks. It is used by advertisers to track the performance of their ads and optimize their campaigns. For our purposes, we will assume these are ads displayed on a website or app, like Facebook.

Functional Requirements

Core Requirements

1. Users can click on an ad and be redirected to the advertiser’s website
2. Advertisers can query ad click metrics over time with a minimum granularity of 1 minute

Below the line (out of scope):

• Ad targeting
• Ad serving
• Cross device tracking
• Integration with offline marketing channels

Non-Functional Requirements

Before we jump into our non-functional requirements, it’s important to ask your interviewer about the scale of the system. For this design in particular, the scale will have a large impact on the database design and the overall architecture.

We are going to design for a system that has 10M active ads and a peak of 10k clicks per second. The total number of clicks per day will be around 100M.

With that in mind, let’s document the non-functional requirements:

Core Requirements

1. Scalable to support a peak of 10k clicks per second
2. Low latency analytics queries for advertisers (sub-second response time)
3. Fault tolerant and accurate data collection. We should not lose any click data.
4. As realtime as possible. Advertisers should be able to query data as soon as possible after the click.
5. Idempotent click tracking. We should not count the same click multiple times.

Below the line (out of scope):

• Fraud or spam detection
• Demographic and geo profiling of users
• Conversion tracking

Here’s how it might look on your whiteboard:

The Set Up

Planning the Approach

For this question, which is less of a user-facing product and more focused on data processing, we’re going to follow the delivery framework outlined here, focusing on the system interface and the data flow.

System Interface

For data processing questions like this one, it helps to start by defining the system’s interface. This includes clearly outline what data the system receives and what it outputs, establishing a clear boundary of the system’s functionality. The inputs and outputs of this system are very simple, but it’s important to get these right!

1. Input: Ad click data from users.
2. Output: Ad click metrics for advertisers.

Data Flow

The data flow is the sequential series of steps we’ll cover in order to get from the inputs to our system to the outputs. Clarifying this flow early will help to align with our interviewer before the high-level design. For the ad click aggregator:

1. User clicks on an ad on a website.
2. The click is tracked and stored in the system.
3. The user is redirected to the advertiser’s website.
4. Advertisers query the system for aggregated click metrics.

Note that this is simple, we will improve upon as we go, but it’s important to start simple and build up from there.

High-Level Design

1) Users can click on ads and be redirected to the target

Let’s start with the easy part, when a user clicks on an ad in their browser, we need to make sure that they’re redirected to the advertiser’s website. We’ll introduce a Ad Placement Service which will be responsible for placing ads on the website and associating them with the correct redirect URL.

When a user clicks on an ad which was placed by the Ad Placement Service, we will send a request to our /click endpoint, which will track the click and then redirect the user to the advertiser’s website.

There are two ways we can handle this redirect, with one being simpler and the other being more robust.

Good Solution: Client side redirect

Approach

The simplest thing we can do is send over a redirect URL with each ad that’s placed on the website. When a user clicks on the ad, the browser will automatically redirect them to the target URL. It’s simple, straightforward, and requires no additional server side logic. We would then, in parallel, POST to our /click endpoint to track the click.

Challenges

The downside with this approach is that users could go to an advertiser’s website without us knowing about it. This could lead to discrepancies in our click data and make it harder for advertisers to track the performance of their ads. Sophisticated users could grab the url off of the page and navigate to it directly, bypassing our click tracking entirely. Someone would probably build a browser extension to do this.

Great Solution: Server side redirect

Approach

A more robust solution is to have the user click on the ad, which will then send a request to our server. Our server can then track the click and respond with a redirect to the advertiser’s website via a 302 (redirect) status code.

This way, we can ensure that we track every click and provide a consistent experience for users and advertisers. This approach also allows us to append additional tracking parameters to the URL, which can help the advertiser track the source of the click, but this is out of scope so we won’t go into more detail here.

Challenges

The only downside is the added complexity, which could slow down the user experience. We need to make sure that our system can handle the additional load and respond quickly to the user’s request.

2) Advertisers can query ad click metrics over time at 1 minute intervals

Our users were successfully redirected, now let’s focus on the advertisers. They need to be able to quickly query metrics about their ads to see how they’re performing. We’ll expand on the click processor path that we introduced above by breaking down some options for how a click is processed and stored.

Once our /click endpoint receives a request what happens next?

Read the rest of this article (for free, no signup) here!

Understanding the Problem

🎟️ What is Ticketmaster? Ticketmaster is an online platform that allows users to purchase tickets for concerts, sports events, theater, and other live entertainment.

Functional Requirements

Core Requirements

1. Users should be able to view events
2. Users should be able to search for events
3. Users should be able to book tickets to events

Below the line (out of scope):

• Users should be able to view their booked events
• Admins or event coordinators should be able to add events
• Popular events should have dynamic pricing

Non-Functional Requirements

Core Requirements

1. The system should prioritize availability for searching & viewing events, but should prioritize consistency for booking events (no double booking)
2. The system should be scalable and able to handle high throughput in the form of popular events (10 million users, one event)
3. The system should have low latency search (< 500ms)
4. The system is read heavy, and thus needs to be able to support high read throughput (100:1)

Below the line (out of scope):

• The system should protect user data and adhere to GDPR
• The system should be fault tolerant
• The system should provide secure transactions for purchases
• The system should be well tested and easy to deploy (CI/CD pipelines)
• The system should have regular backups

Here is how the requirements might look on the whiteboard:

Adding features that are out of scope is a “nice to have”. It shows product thinking and gives your interviewer a chance to help you reprioritize based on what they want to see in the interview. That said, it’s very much a nice to have. If additional features are not coming to you quickly, don’t waste your time and move on.

Planning the Approach

Before you move on to designing the system, it’s important to start by taking a moment to plan your strategy. Fortunately, for these common user-facing product-style questions, the plan should be straightforward: build your design up sequentially, going one by one through your functional requirements. This will help you stay focused and ensure you don’t get lost in the weeds as you go. Once you’ve satisfied the functional requirements, you’ll rely on your non-functional requirements to guide you through the deep dives.

Defining the Core Entities

I like to begin with a broad overview of the primary entities. At this stage, it is not necessary to know every specific column or detail. We will focus on the intricacies, such as columns and fields, later when we have a clearer grasp. Initially, establishing these key entities will guide our thought process and lay a solid foundation as we progress towards defining the API.

To satisfy our key functional requirements, we’ll need the following entities:

1. Event: This entity stores essential information about an event, including details like the date, description, type, and the performer or team involved. It acts as the central point of information for each unique event.
2. User: Represents the individual interacting with the system. Needs no further explanation.
3. Performer: Represents the individual or group performing or participating in the event. Key attributes for this entity include the performer’s name, a brief description, and potentially links to their work or profiles. (Note: this could be artist, company, collective — a lot of different entities. The choice of “performer” is intending to be general enough to cover all possible groups)
4. Venue: Represents the physical location where an event is held. Each venue entity includes details such as address, capacity, and a specific seat map, providing a layout of seating arrangements unique to the venue.
5. Ticket: Contains information related to individual tickets for events. This includes attributes such as the associated event ID, seat details (like section, row, and seat number), pricing, and status (available or sold).
6. Booking: Records the details of a user’s ticket purchase. It typically includes the user ID, a list of ticket IDs being booked, total price, and booking status (such as in-progress or confirmed). This entity is key in managing the transaction aspect of the ticket purchasing process.

In the actual interview, this can be as simple as a short list like this. Just make sure you talk through the entities with your interviewer to ensure you are on the same page.

As you move onto the design, your objective is simple: create a system that meets all functional and non-functional requirements. To do this, I recommend you start by satisfying the functional requirements and then layer in the non-functional requirements afterward. This will help you stay focused and ensure you don’t get lost in the weeds as you go.

API or System Interface

The API for viewing events is straightforward. We create a simple GET endpoint that takes in an eventId and return the details of that event.

GET /events/:eventId -> Event & Venue & Performer & Ticket[]
- tickets are to render the seat map on the Client

In most instances, your interviewer will be able to read between the lines of your core entities and the requirement we’re satisfying to understand the data returned by the API. They will either tell you or you can ask them if they’d like you to go into additional detail but be cautious about being over-verbose — you have a lot of ground to cover and enumerating the fields in the Event object may not be the best use of your time!

Next, for search, we just need a single GET endpoint that takes in a set of search parameters and returns a list of events that match those parameters.

GET /events/search?keyword={keyword}&start={start_date}&end={end_date}&pageSize={page_size}&page={page_number} -> Event[]

When it comes to purchasing/booking a ticket, we have a post endpoint that takes the list of tickets and payment payment details and returns a bookingId.

Later in the design, we’ll evolve this into two separate endpoints — one for reserving a ticket and one for confirming a purchase, but this is a good starting point.

POST /bookings/:eventId -> bookingId
 {
   "ticketIds": string[], 
   "paymentDetails": ...
 }

It’s ok to have simple APIs from the start that you evolve as your design progresses. As always, just communicate, “Here is a simple API to start, but as we get into the design, we’ll likely need to evolve this to handle more complex scenarios.”

High-Level Design

1) Users should be able to view events

When a user navigates to www.yourticketmaster.com/event/:eventId they should see details about that event. Crucially, this should include a seatmap showing seat availability. The page will also display the event’s name, along with a description. Key information such as the location (including venue details), event dates, and facts about the performers or teams involved could be outlined.

We start by laying out the core components for communicating between the client and our microservices. We add our first service, “Event Service,” which connects to a database that stores the event, venue, and performer data outlined in the Core Entities above. This service will handle the reading/viewing of events

1. Clients: Users will interact with the system through the clients website or app. All client requests will be routed to the system’s backend through an API Gateway.
2. API Gateway: This serves as an entry point for clients to access the different microservices of the system. It’s primarily responsible for routing requests to the appropriate services but can also be configured to handle cross-cutting concerns like authentication, rate limiting, and logging.
3. Event Service: Our first microservice is responsible for handling view API requests by fetching the necessary event, venue, and performer information from the database and returning the results to the client.
4. Events DB: Stores tables for events, performers, and venues.

Let’s walk through exactly what happens when a user makes a request to www.yourticketmaster.com/event/:eventId to view an event.

1. The client makes a REST GET request with the eventId
2. The API gateway then forwards the request onto our Event Service.
3. The Event Service then queries the Events DB for the event, venue, and performer information and returns it to the client.

2) Users should be able to search for events

Sweet, we now have the core functionality in place to view an event! But how are users supposed to find events in the first place? When users first open your site, they expect to be able to search for upcoming events. This search will be parameterized based on any combination of keywords, artists/teams, location, date, or event type.

Let’s start with the most basic thing you could do — we’ll create a simple service which accepts search queries. This service will connect your DB and query it by filtering for the fields in the API request. This has issues, but it’s a good starting point. We will dig into better options in the deep dives below.

When a user makes a search request, it’s straightforward:

1. The client makes a REST GET request with the search parameters
2. Our load balancer accepts the request and routes it to the API gateway with the fewest current connections.
3. The API gateway then, after handling basic authentication and rate limiting, forward the request onto our Search Service.
4. The Search Service then queries the Events DB for the events matching the search parameters and returns them to the client.

Don’t stop here! Read the rest of the design here.

(Don’t worry, it’s 100% free)

The easiest way to sabotage your chances of getting an offer in your system design interview is to fail to deliver a working system. This is the most common reason that mid-level candidates fail these interviews. While a firm structure to your approach is important and your interviewer is not trained specifically to assess you on your delivery (often this gets bucketed into “communication”), in practice we’ve seen many candidates that perform significantly better by following a structure which both keeps them from getting stuck and ensures they deliver a working system.

Requirements (~5 minutes)

The goal of the requirements section is to get a clear understanding of the system that you are being asked to design. To do this, we suggest you break your requirements into two sections.

1) Functional Requirements

Functional requirements are your “Users/Clients should be able to…” statements. These are the core features of your system and should be the first thing you discuss with your interviewer. Oftentimes this is a back and fourth with your interviewer. Ask targeted questions as if you were talking to a client, customer, or product manager (“does the system need to do X?”, “what would happen if Y?”) to arrive at a prioritized list of core features.

For example, if you were designing a system like Twitter, you might have the following functional requirements:

• Users should be able to post tweets
• Users should be able to follow other users
• Users should be able to see tweets from users they follow

A cache meanwhile might have requirements like:

• Clients should be able to insert items
• Clients should be able to set expirations
• Clients should be able to read items

Keep your requirements targeted! The main objective in the remaining part of the interview is to develop a system that meets the requirements you’ve identified — so it’s crucial to be strategic in your prioritization. Many of these systems have hundreds of features, but it’s your job to identify and prioritize the top 3. Having a long list of requirements will hurt you more than it will help you and many top FAANGs directly evaluate you on your ability to focus on what matters.

2) Non-functional Requirements

Non-functional requirements are statements about the system qualities that are important to your users. These can be phrased as “The system should be able to…” or “The system should be…” statements.

For example, if you were designing a system like Twitter, you might have the following non-functional requirements:

• The system should be highly availability, prioritizing availability over consistency
• The system should be able to scale to support 100M+ DAUs
• The system should be low latency, rendering feeds in under 200ms

It’s important that non-functional requirements are put in the context of the system and, where possible, are quantified. For example, “the system should be low latency” is obvious and not very meaningful — nearly all systems should be low latency. “The system should have low latency search, < 500ms,” is much more useful as it identifies the part of the system that most needs to be low latency and provides a target.

Coming up with non-functional requirements can be challenging, especially if you’re not familiar with the domain. Here is a checklist of things to consider that might help you identify the most important non-functional requirements for your system. You’ll want to identify the top 3–5 that are most relevant to your system.

1. CAP Theorem: Should your system prioritize consistency or availability? Note, partition tolerance is a given in distributed systems.
2. Environment Constraints: Are there any constraints on the environment in which your system will run? For example, are you running on a mobile device with limited battery life? Running on devices with limited memory or limited bandwidth (e.g. streaming video on 3G)?
3. Scalability: All systems need to scale, but does this system have unique scaling requirements? For example, does it have bursty traffic at a specific time of day? Are there events, like holidays, that will cause a significant increase in traffic? Also consider the read vs write ratio here. Does your system need to scale reads or writes more?
4. Latency: How quickly does the system need to respond to user requests? Specifically consider any requests that require meaningful computation. For example, low latency search when designing Yelp.
5. Durability: How important is it that the data in your system is not lost? For example, a social network might be able to tolerate some data loss, but a banking system cannot.
6. Security: How secure does the system need to be? Consider data protection, access control, and compliance with regulations.
7. Fault Tolerance: How well does the system need to handle failures? Consider redundancy, failover, and recovery mechanisms.
8. Compliance: Are there legal or regulatory requirements the system needs to meet? Consider industry standards, data protection laws, and other regulations.

3) Capacity Estimation

Many guides you’ve read will suggest doing back-of-the-envelope calculations at this stage. We believe this is often unnecessary. Instead, perform calculations only if they will directly influence your design. In most scenarios, you’re dealing with a large, distributed system — and it’s reasonable to assume as much. Many candidates will calculate storage, DAU, and QPS, only to conclude, “ok, so it’s a lot. Got it.” As interviewers, we gain nothing from this except that you can perform basic arithmetic.

Our suggestion is to explain to the interviewer that you would like to skip on estimations upfront and that you will do math while designing when/if necessary. When would it be necessary? Imagine you are designing a TopK system for trending topics in FB posts. You would want to estimate the number of topics you would expect to see, as this will influence whether you can use a single instance of a data structure like a min-heap or if you need to shard it across multiple instances, which will have a big impact on your design.

Regardless of how you end up using it in the interview, learning to estimate relevant quantities quickly will help you quick reason through design trade-offs in your design. Don’t worry if you’re not good at mental arithmetic under pressure, most people aren’t.

Head over to Hello Interview to continue reading!

(don’t worry, it’s totally free)

Intro

DynamoDB is a fully-managed, highly scalable, key-value service provided by AWS. Cool, buzz-words. But what the hell does that mean and why does it matter?

• Fully-Managed — This means that AWS takes care of all the operational aspects of the database. The fully-managed nature allows AWS to handle all operational tasks — hardware provisioning, configuration, patching, and scaling — freeing developers to concentrate on application development.
• Highly Scalable — DynamoDB can handle massive amounts of data and traffic. It automatically scales up or down to adjust to your application’s needs, without any downtime or performance degradation.
• Key-value — DynamoDB is a NoSQL database, which means it doesn’t use the traditional relational database model. Instead, it uses a key-value model that allows for flexible data storage and retrieval.

The moral of the story is that DynamoDB is a super easy to use and can scale to support a wide variety of applications. For system design interviews in particular, it has just about everything you’d ever need from a database. It even supports transactions now! Which neutralizes one of the biggest criticisms of DynamoDB in the past.

Importantly, DynamoDB is not open-source, so we can’t as easily describe its internals like we did with breakdowns of open source technologies like Kafka and Redis. Instead, we’ll focus more on you interact with it. In order to look under the hood, we’ll rely on the limited information AWS provides via documentation and the DynamoDB Whitepaper.

In this deep dive, we’ll break down exactly what you need to know about DynamoDB in order to field any question about it in a system design interview. Along the way, you’ll also acquire practical learning that you can later apply in your own projects. Let’s break it down!

Candidates often ask me, “am I even allowed to use DynamoDB in an interview?”

The answer is simple, ask your interviewer! Many will say yes, and just expect that you know how to use it. Others may say no, expecting open-source alternatives that avoid any vendor lock-in. As is always the case, just ask 😊

The Data Model

In DynamoDB, data is organized into tables, where each table has multiple items that represent individual records. This is just like a relational database, but with some distinct differences tailored for scalability and flexibility.

Tables — Serve as the top-level data structure in DynamoDB, each defined by a mandatory primary key that uniquely identifies its items. Tables support secondary indexes, enabling queries on non-primary key attributes for more versatile data retrieval.

Items — Correspond to rows in a relational database and contain a collection of attributes. Each item must have a primary key and can contain up to 400KB of data, including all its attributes.

Attributes — Key-value pairs that constitute the data within an item. They can vary in type, including scalar types (strings, numbers, booleans) and set types (string sets, number sets). Attributes can also be nested, allowing for complex data structures within a single item.

Setting up DynamoDB is straightforward: you can create tables directly in the AWS console, and start inserting data immediately. Unlike traditional RDBMS, DynamoDB is schema-less, meaning you don’t need to define a schema before inserting data. This means items in the same table can have different sets of attributes, and new attributes can be added to items at any point without affecting existing items. This schema-less design provides high flexibility but requires careful data validation at the application level, as DynamoDB does not enforce attribute uniformity across items.

Consider a users table in DynamoDB, structured as follows:

{
  "PersonID": 101,
  "LastName": "Smith",
  "FirstName": "Fred",
  "Phone": "555-4321"
},
{
  "PersonID": 102,
  "LastName": "Jones",
  "FirstName": "Mary",
  "Address": {
    "Street": "123 Main",
    "City": "Anytown",
    "State": "OH",
    "ZIPCode": 12345
  }
},
{
  "PersonID": 103,
  "LastName": "Stephens",
  "FirstName": "Howard",
  "Address": {
    "Street": "123 Main",
    "City": "London",
    "PostalCode": "ER3 5K8"
  },
  "FavoriteColor": "Blue"
}

Each item represents a user with various attributes. Notice how some users have attributes not shared by others, like FavoriteColor, showing DynamoDB’s flexibility in attribute management.

Although DynamoDB uses JSON for data transmission, it’s merely a transport format. The actual storage format of DynamoDB is proprietary, allowing users to focus on data modeling without delving into the complexities of physical data storage.

Partition Key and Sort Key

DynamoDB tables are defined by a primary key, which can consist of one or two attributes:

1. Partition Key — A single attribute that uniquely identifies each item in the table. DynamoDB uses the partition key’s value to determine the physical location of the item within the database. This value is hashed to determine the partition where the item is stored.
2. Sort Key (Optional) — An additional attribute that, when combined with the partition key, forms a composite primary key. The sort key is used to order items with the same partition key value, enabling efficient range queries and sorting within a partition.

In an interview, you’ll want to be sure to specify the partition key and, optionally, a sort key when introducing DynamoDB. This choice is important for optimizing query performance and data retrieval efficiency. Just like with any other database, you’ll choose a partition key that optimizes for the most common query patterns in your application and keeping data evenly distributed across partitions. In the case you need to perform range queries or sorting, you’ll want to also specify the Sort Key.

For example, if you’re building a simple group chat application, it would make sense to use the chat_id as the partition key and timestamp as the sort key. This way, you can efficiently query all messages for a specific chat group and sort them by timestamp before displaying them to users.

But what is actually happening under the hood?

DynamoDB uses a combination of consistent hashing and B-trees to efficiently manage data distribution and retrieval:

1. Consistent Hashing for Partition Keys:

• The partition key is hashed using a consistent hashing function.
• This hash value determines which physical node (or partition) in the DynamoDB cluster will store the item.
• Consistent hashing ensures even distribution of data across nodes and facilitates easy scaling.

2. B-trees for Sort Keys:

• Within each partition, items are organized using a B-tree data structure, which is a self-balancing tree stored on disk.
• The B-tree is indexed on the sort key, allowing for efficient range queries and sorted retrieval.
• This structure enables quick lookups, insertions, and deletions within a partition.

3. Composite Key Operations:

• When querying with both partition and sort keys, DynamoDB first uses the partition key’s hash to locate the correct node.
• It then traverses the B-tree on that node using the sort key to find the specific item or range of items.

This two-tier approach allows DynamoDB to achieve both horizontal scalability (through partitioning) and efficient querying within partitions (through B-tree indexing). It’s this combination that enables DynamoDB to handle massive amounts of data while still providing fast, predictable performance for queries using both partition and sort keys.

Head over to Hello Interview to continue reading!

(don’t worry, it’s totally free)

Intro

There is a good chance you’ve heard of Kafka. It’s popular. In fact, according to their website, it’s used by 80% of the Fortune 100. If it’s good enough to help scale the largest companies in the world, it’s probably good enough for your next system design interview. In fact, it’s one of the top 5 technologies we see used in design interviews.

Apache Kafka is an open-source distributed event streaming platform that can be used either as a message queue or as a stream processing system. Kafka excels in delivering high performance, scalability, and durability. It’s engineered to handle vast volumes of data in real-time, ensuring that no message is ever lost and that each piece of data is processed as swiftly as possible.

In this deep dive, we’re going to take a top down approach. Starting with a zoomed out view of Kafka and progressing into more and more detail. If you know the basics, feel free to skip ahead to the more advanced sections.

A Motivating Example

It’s the World Cup (my personal favorite competition). And we run a website that provides real-time statistics on the matches. Each time a goal is scored, a player is booked, or a substitution is made, we want to update our website with the latest information.

Events are placed on a queue when they occur. We call the server or process responsible for putting these events on the queue the producer. Downstream, we have a server that reads events off the queue and updates the website. We call this the consumer.

Now, imagine the World Cup expanded from just the top 48 teams to a hypothetical 1,000-team tournament, and all the games are now played at the same time. The number of events has increased significantly, and our single server hosting the queue is struggling to keep up. Similarly, our consumer feels like it has its mouth under a firehose and is crashing under the load.

We need to scale the system by adding more servers to distribute our queue. But how do we ensure that the events are still processed in order?

If we were to randomly distribute the events across the servers, we would have a mess on our hands. Goals would be scored before the match even started, and players would be booked for fouls they haven’t committed yet.

A logical solution is to distribute the items in the queue based on the game they are associated with. This way, all events for a single game are processed in order because they exist on the same queue. This is one of the fundamental ideas behind Kafka: messages sent and received through Kafka require a user specified distribution strategy.

But what about our consumer, it’s still overwhelmed. It is easy enough to add more, but how do we make sure that each event is only processed once? We can group consumers together into what Kafka calls a consumer group. With consumer groups, ach event is guaranteed to only be processed by one consumer in the group.

Lastly, we’ve decided that we want to expand our hypothetical World Cup to more sports, like basketball. But we don’t want our soccer website to cover basketball events, and we don’t want our basketball website to cover soccer events. So we introduce the concept of topics. Each event is associated with a topic, and consumers can subscribe to specific topics. Therefore, our consumers who update the soccer website only subscribe to the soccer topic, and our consumers that update the basketball website only subscribe to basketball events.

Basic Terminology and Architecture

The example is great, but let’s define Kafka a but more concretely by formalizing some of the key terms and concepts introduced above.

A Kafka cluster is made up of multiple brokers. These are just individual servers (they can be physical or virtual). Each broker is responsible for storing data and serving clients. The more brokers you have, the more data you can store and the more clients you can serve.

Each broker has a number of partitions. Each partition is an ordered, immutable sequence of messages that is continually appended to — think of like a log file. Partitions are the way Kafka scales as they allow for messaged to be consumed in parallel.

A topic is just a logical grouping of partitions. Topics are the way you publish and subscribe to data in Kafka. When you publish a message, you publish it to a topic, and when you consume a message, you consume it from a topic. Topics are always multi-producer; that is, a topic can have zero, one, or many producers that write data to it.

So what is the difference between a topic and a partition?

A topic is a logical grouping of messages. A partition is a physical grouping of messages. A topic can have multiple partitions, and each partition can be on a different broker. Topics are just a way to organize your data, while partitions are a way to scale your data.

Last up we have our producers and consumers. Producers are the ones who write data to topics, and consumers are the ones who read data from topics. While Kafka exposes a simple API for both producers and consumers, the creation and processing of messages is on you, the developer. Kafka doesn’t care what the data is, it just stores and serves it.

Importantly, you can use Kafka as either a message queue or a stream. Frankly, the distinction here is minor. The only meaningful difference is with how consumers interact with the data. In a message queue, consumers read messages from the queue and then acknowledge that they have processed the message. In a stream, consumers read messages from the stream and then process them, but they don’t acknowledge that they have processed the message. This allows for more complex processing of the data.

Head over to Hello Interview to read the rest of the breakdown!

(don’t worry, it’s totally free)

When it comes to the Meta design interview, they let you choose between a System Design interview and a Product Architecture interview. Not sure what the difference is? Checkout this blog post I wrote on the topic.

But anyway, I know what you’re here for. In my experience, here are the questions that are most commonly asked for each interview type.

Read the linked breakdowns, definitely, but these aren’t interviews where you can just memorize an answer key, so don’t treat them as such. Use them to learn the underlying concepts and frameworks for tackling these types of problems.

System Design

1. Design an Ad Click Aggregator
2. Design a Top K Service
3. Design Memcached
4. Design FB Live Comments
5. Design TAO
6. Design Uber
7. Design Ticketmaster
8. Design a Distributed Job Scheduler

Product Architecture

1. Design Ticketmaster
2. Design Uber
3. Design IG Auction
4. Design Dropbox
5. Design Newsfeed
6. Design Facebook i18n
7. Design Just the UX and APIs for Newsfeed
8. Design Leetcode
9. Design Messenger