A Senior Engineer’s Guide to the System Design Interview (Part 4)#

Article: https://interviewing.io/guides/system-design-interview/part-four


  • Going through example designs as an exercise for the framework.

  • Using Pastebin as a simplest example.

  • Gather requirements:

    • Starting with functional requirements. Objects and their interactions.

    • The data is immutable for simplicity.

    • Extra considerations: analytics, monetization, legal.

    • Non-functional requirements: availability, consistency, durability, scalability, latency.

    • Check with interviewer if you missed something.

    • Estimates are used to justify building a complex distributed system. Ask your interviewer if they’d like to see some calculations.

    • Estimate storage and bandwidth. Use 100K seconds per day (15% error).

  • Data Types, API and Scale:

    • Using NoSQL database, because transactions and joins are not needed.

    • Explaining API as RESTful, because there’s no batching, streaming, and push notifications.

    • Iterating to add mutability.

  • Design: ???

  • Suddenly, topic switches to a distributed Unique ID generation.

  • A lot of math to say “use 128-bit keys, possibly UUID4.”

  • Jump to “AOL Instant Messenger.”

  • Functional requirements: have auth, send messages.

  • Non-functional requirements: eventual consistency, high availability, durability.

  • Skipped data types, API, and scale.

  • Design. Classic sandwich: load-balancer, middleware, sharded replicated database.

  • Jump to “Design Ticketmaster” (Trying on my own before reading.)

    • Organizers create events.

    • People buy tickets and attend events.

    • Entities: organizer, person, event, ticket.

    • Functional requirements:

      • Organizer creates event and sets the numbers and kinds of available tickets.

      • Organizer can list their (immutable) events.

      • Person can list and filter (search) available events.

      • Person can purchase a ticket for an event. Reservation?

      • Person can view purchase history.

      • Venue stuff can punch tickets.

      • Extra: return tickets, cancel events, change events, transfer tickets.

    • Non-functional requirements:

      • Strict consistency: no double-booking.

      • High availability.

      • Fast purchase, event creation can be slower.

      • High durability for upcoming events. Not so much for past events.

    • Data storage:

      • Organizer: contract, collateral.

      • Events: date, description, images, videos. Comments?

      • Venues: sitting plan.

      • Tickets: price, amount, type/name, sit number, virtual.

      • People: email, payment method, notifications, promotions.

      • SQL database for structured data, Blob storage for media.

      • Seat occupancy cache.

      • Shard by event.

    • API:

      • POST /event/

      • GET /event/{event_id}/

      • GET /event/{event_id}/ticket/

      • POST /event/{event_id}/ticket/

      • GET /event/{event_id}/ticket/{ticket_id}/

      • GET /ticket/

      • GET /search/event/?location=…&dates=…

    • Scalability:

      • Traffic is spiky, hot events will have thousands of users trying to by tickets as as they’re available.

      • 10K RPM for sales.

      • Several events launching at the same time.

      • Read-only fallback

      • Synchronous replication from leader

      • Replicas close-by

    • Design:

      • Services

      • Database

      digraph database {
edge [color="#808080", arrowsize=.6, penwidth=3, minlen=3];
node [shape=box, fontname="DIN Next, sans-serif", style="rounded,filled", penwidth=5, fillcolor="#8010d0", color="#f0f0f0", fontcolor=white,  margin="0.35" fontweight=bold]


Users -> Seats [label="1 to many"]
Users -> Tickets [label="1 to many"]
Events -> Seats [label="1 to many"]
Events -> Tickets [label="1 to many"]
Tickets -> Seats [label="1 to 1"]
      • Tickets:

        • event_id

        • seat_id

        • reserved_by

        • reserved_at

        • purchased_by


Exercises helped with understanding the steps of the framework better. Following the process demonstrates a systematic approach to design. Guide references to differences between junior, senior, and staff engineers, but doesn’t provide a good framework for what you should be looking out for to demonstrate your seniority.