.svg)
.svg)
System design interview questions are a critical part of Full Stack interviews. Top tech companies, including FAANG, use system design interview questions to gauge your understanding of and proficiency in building highly scalable systems.
This article, written by an Interview Kickstart mentor, Ashish, outlines the best strategy to answer system design interview questions at a full stack engineering interview.
If you are preparing for a full stack interview, the insights from this article will help you in understanding the aspects of technical conversation that occur during the system design round. You will also know what interviewers expect from a senior engineer in interview settings, which will help you prepare for such challenges.
We’ll do this with the help of a sample interview. Here’s what we’ll cover:
- Full Stack System Design Sample Interview Questions and Answers — Design an Events Website
- Key Takeaways
Full Stack System Design Sample Interview Questions and Answers
Design an Events Website
Q. Imagine you are a founder of a website that wants to sell tickets for events online. Discuss a plan for releasing a minimum viable product (MVP) website for this startup and define an architecture to support the requirements.
The following is a representation of a real-life Full Stack System Design interview setting involving a technical architect/staff engineer. We’ve listed examples of follow-up questions to the question listed above and ideal answers for each.
This interview is purely fictitious, and any resemblance to a real-life setting is coincidental.
Interviewer:
Identify the high-level functionality of this system that you think is crucial in the MVP, given you have funding for the next 6 months of the project.
Candidate:
The application seems to be a consumer app that has two types of users:
- The publishers who own and publish the events on the website
- The customers who would like to purchase tickets to those events
The MVP scope can therefore include the following use cases for these users:
Publishers:
- Authentication
- Define an event (and modify existing ones)
- Define tickets and pricing (or modify existing ones)
- Map of venue
- Date(s)/time(s)/other constraints (# of tickets)
Customers:
- Authentication
- Search for events
- Event details
- Ticket prices
- Map of venue/ticket placement
- Checkout flow
- View purchased tickets
Interviewer:
Define the characteristics of the system; high-level system architecture.
Candidate:
Type of system:
- Consumer-centric application.
- The app is read-heavy as most operations are around searching and browsing events.
- In some cases, we may have spikes in transactions/writes when there are high-velocity selloffs for popular events.
- The checkout flow is similar to other reservation systems, e.g., airlines, but perhaps with less convergence. There are similar challenges of securing seats during reservation.
Clarifying question by the Candidate:
What are the scaling parameters, like the number of concurrent users, total users, and expected number of checkouts at any given time?
Interviewer:
Assume and estimate as the product is new and designed for horizontal scaling.
Candidate:
Start with N tier high-level architecture:
- Web app (consumer): Consumer focus and hence the emphasis on user experience is a must.
- Web app (publisher): Enterprise focus and prioritizes functional features over user experience.
- Frontend API layer: Defines REST interface for frontend - backend communication.
- Business application layer (cloud functions): Defines the business logic, workflows, and transactions.
- Database: For storing all events, maps, transactions, and payments.
Architectural diagram:
Interviewer:
What kind of database should we use for this purpose?
Candidate:
We can consider two kinds of databases:
- NoSQL: Works best for representing dynamic/nested schema for events and seating, etc.
- SQL: Works best for transactions and payments.
Since we have both kinds of use cases, we shall employ both servers.
Interviewer:
How do we scale the database?
Candidate:
We can introduce a cache of events with reasonable TTL that is based on the LRU scheme and shard it geographically. Something like memcached or redis cache should work just fine.
Interviewer:
How do you implement the business application layer?
Candidate:
We can use step functions to represent workflows. They involve less integration code, have built-in fault tolerance and stateful workflows, and can scale reliability in the cloud.
Interviewer:
How would you implement the frontend API layer?
Candidate:
We can use lambdas with API gateway for a simple REST or GraphQL interface. GraphQL is great as it provides query, search, and aggregation capabilities out of the box and can optimize queries by reducing the number of requests/responses for entities.
Interviewer:
Can you provide some breakdown of APIs?
Candidate:
Let’s work backward and drive the API design based on UI requirements.
Interviewer:
Sure, let's talk about the publisher website first?
Candidate:
Actually, because we are under time constraints and do not have many development resources, we can pick a metro as a startup MVP supported city, remove the requirement of a publisher website altogether, and use some back-office software (like Google Sheets, AppSheet) to ingest events, venue, date times, maps and ticket prices.
(These are examples of prudent and practical tradeoffs that Architects often make keeping business goals in mind!)
Interviewer:
Interesting, how do you ingest venue maps and associate them with ticket prices and quantity?
Candidate:
We can be creative. Squarish/Rectangular areas are easier to construct, even in spreadsheets. We can use them for MVP, and if this is too limiting, we can simply create pictures and use image maps in HTML to associate them with seating and pricing.
Even better, we can annotate them using tools and then provide seating numbers and decouple pricing by joining several pieces of metadata (venue, date, time, location) with the price.
Interviewer:
Ok. Let’s assume we have the data ingested. Define the pages for the customer website frontend.
Candidate:
A possible sitemap will include:
- Homepage (location-aware using HTML5 APIs) with search option
- Search for events (location, date, time, type of event)
- Event detail page (links to purchase tickets)
- Shopping cart page (displays in-basket tickets with checkout options)
- Authentication (social authentication) (optional if purchasing as a guest)
- Profile (name, age, location, etc.)
- Checkout page (# of tickets, date, time, location, seating quantity, and placement)
- Confirmation page/transaction summary/email purchased tickets (with QR codes)
Interviewer:
One issue you may face, particularly for popular events, is multiple customers attempting to purchase tickets for the conflicting seating range. How do you ensure seat selection does not involve conflicts when a customer is selecting or proceeding with a transaction?
Candidate:
We can try and minimize conflicts by:
- Providing a limited-time hold on tickets in a cart and aborting the hold in case a transaction does not complete within the hold period.
- Provide default selection for free seats at the time of request hoping customers will pick the default selection.
- Sectioning the space beforehand for 2, 3, 4, 5, or more seats and only display specific sections based on quantity.
- Continually update seats via real-time communication (WebSockets).
- Chunk space into segments and provide a section of space to the user to reduce conflicts.
- Some conflicts can still occur amidst parallel transactions, so we can reject requests.
Interviewer:
It's hard to do unbounded transitions in parallel in a way that prevents conflicts from arising; what else can you do to minimize conflicts?
Candidate:
Database conflicts can degrade performance, owing to an increase in database locks and aborted transactions. We can follow the above ideas (or use WebSockets for near-real-time seating access) and have a queuing mechanism where each request can be worked upon by lambda triggers.
UI can use polling to query the status of the reservation. This also works under choppy network conditions. We can send an email when a reservation is confirmed or denied. Even better, in late conflict situations, we can select alternate seats for the customer and have an option to cancel (possibly?).
Interviewer:
Let’s now define entities and relationships.
Candidate:
The main entities in this app are:
- Customer: Browse events, purchase tickets
- Publisher: Publish events, tickets, venue, and prices for tickets
- Event: Represent an event that has a venue, event instances at a geographical location
- Event Instance: An instance of an event at a particular venue at a particular day/time
- Tickets: A definition of a ticket at a location within a venue
- Ticket Instance: An instance of ticket bound to a particular event instance and price
- Venue Map: Map for an event instance defining several ticket locations
- Geographic Location: Location for an event
- Payment Instruments: Represents credit cards and other means of payment
- Transaction: Represents a ticket purchase by a customer sold by a publisher
ER diagram:
Interviewer:
How would you handle payments in your system?
Candidate:
Payments require a domain specialization, and secure storage of payment information is a P0 requirement for any e-commerce application. For this reason, we shall rely on a credible payments provider, like Stripe, such that we can focus on the core business proposition and leave payment management to experts.
Stripe provides excellent APIs to handle interactive and passive payment options for both one-time and recurrent payments.
Interviewer:
How would you handle large parties (more than 10, let’s say)?
Candidate:
Since this is a special arrangement, we would allow customer service to book tickets for large parties, at least in the MVP.
Key Takeaways
The interaction above is the perfect example of a structured interview strategy. The candidate sends a great signal to the interviewer about their relative seniority.
Let’s break down the key components of the approach taken by the candidate:
1. Scope Fencing
The candidate begins by negotiating and clarifying requirements and correctly classifying the application to be a consumer application and then identifies use cases for the application to define the MVP scope.
This scope fencing is important before sketching any architecture for the system, as we are focussed on a specified set of requirements.
2. Start and Enhance
After that, the candidate proposes an architecture for the initial MVP requirements and progressively enhances the architecture according to evolving clarifications, ensuring simplicity and preventing over-engineering.
3. Trade-offs
The candidate also made appropriate tradeoffs to release the MVP product by using existing back-office tools (Excel) and focusing on the consumer website rather than building a publishing website.
The choice of one metro city further scopes down the MVP target to an achievable one. At senior levels making and proposing such tradeoffs is a typical thing for software developers.
Similarly, the candidate also assessed the conflicts in transactions owing to high-traffic selloffs and proposed several options to mitigate and lessen the possibility of such conflicts and suggested creative ways to achieve this objective.
Again, another example of tradeoffs and options expected from senior engineers. As we observed, this had an impact on the architecture, and the candidate also proposed the use of queues and lambdas to process transactions.
4. Demonstrate Relevant Skills
Finally, the candidate also demonstrated data modeling skills by identifying entities and relationships for the product along with the cardinality of the relationships.
The candidate also identified security aspects of payments and suggested the use of well-proven payment providers (Stripe) and not use contrived, homegrown payment systems that could lack security. This helps focus the team on MVP business objectives.
Crack Your Next Full Stack Engineer Interview
If you need help with your prep, join Interview Kickstart’s Full Stack Engineering Interview Course — the first-of-its-kind, domain-specific tech interview prep program designed and taught by FAANG+ instructors. Click here to learn more about the program.
IK is the gold standard in tech interview prep. Our programs include a comprehensive curriculum, unmatched teaching methods, FAANG+ instructors, and career coaching to help you nail your next tech interview.
Sign up for our FREE webinar to uplevel your career!
.png)
