Oops! Something went wrong while submitting the form.
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:
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.
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.
The application seems to be a consumer app that has two types of users:
The MVP scope can therefore include the following use cases for these users:
Publishers:
Customers:
Define the characteristics of the system; high-level system architecture.
Type of system:
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.
Start with N tier high-level architecture:
Architectural diagram:
What kind of database should we use for this purpose?
We can consider two kinds of databases:
Since we have both kinds of use cases, we shall employ both servers.
How do we scale the database?
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.
How do you implement the business application layer?
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.
How would you implement the frontend API layer?
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.
Can you provide some breakdown of APIs?
Let’s work backward and drive the API design based on UI requirements.
Sure, let's talk about the publisher website first?
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!)
Interesting, how do you ingest venue maps and associate them with ticket prices and quantity?
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.
Ok. Let’s assume we have the data ingested. Define the pages for the customer website frontend.
A possible sitemap will include:
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?
We can try and minimize conflicts by:
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?
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?).
Let’s now define entities and relationships.
The main entities in this app are:
ER diagram:
How would you handle payments in your system?
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.
How would you handle large parties (more than 10, let’s say)?
Since this is a special arrangement, we would allow customer service to book tickets for large parties, at least in the MVP.
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:
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.
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.
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.
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.
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!
