Domain Knowledge

Overview

Every system design problem lives in a domain, a business context with its own entities, constraints, vocabulary, and behavioral rules. A calendar system has recurring events, timezone conflicts, and attendee availability. A ride-sharing platform has real-time geospatial matching, surge pricing, and driver state machines. A ticketing system has inventory reservation windows, seat maps, and payment finalization races.

Domain knowledge is what separates a candidate who designs a generic CRUD application from one who designs a system that actually solves the problem. Generic designs, "I'll have a users table, a data table, and a cache", score poorly. Domain-aware designs, "for a calendar system, I need to handle recurring event expansion carefully because materializing 100 occurrences of a weekly meeting for every user would be expensive; instead I'll store the recurrence rule and expand on read with a bounded lookahead", score highly.

This is why Problem Framing (Step 1 in the Nalar Linuwih framework) exists as a dedicated step before any architecture work. The first 5 minutes of a system design interview should be spent understanding the domain: what are the core entities, what behaviors are uniquely constrained by this domain, and what are the most critical non-functional requirements given the business context?

This lesson teaches you how to approach any domain you are given, identify its unique constraints, and translate those constraints into technical decisions. It does not require you to be an expert in every domain, it requires you to ask the right questions and reason from first principles.

Core Concepts

Requirement Clarification: Asking the Right Questions

The first thing you do when given a system design problem is not draw a box, it is ask questions. The quality of your questions reveals the quality of your thinking. An interviewer who hears sharp clarifying questions immediately raises their assessment of your seniority.

Three categories of clarifying questions:

Functional scope: What exactly does this system do? What is in scope for this interview?

  • "Should I support anonymous URL shortening, or only authenticated users?"
  • "For the calendar system, should I support recurring events? Timezone-aware scheduling?"
  • "For the ride-sharing platform, is this the full system or a specific component like matching?"

Scale and usage patterns: How is this system used? Who uses it? How often?

  • "How many daily active users are we targeting?"
  • "Is this primarily a read-heavy or write-heavy system?"
  • "Are there specific traffic patterns, like a booking rush when an event goes on sale?"

Business constraints: What are the rules that the business or domain imposes?

  • "For ticketing: do seats need to be held during payment processing? How long can a hold last?"
  • "For calendar: can attendees edit events they were invited to, or only the organizer?"
  • "For ride-sharing: how close does a driver need to be to receive a match request?"

These questions are not stalling tactics, they are information gathering that fundamentally changes your design. If you find out that anonymous URL creation is not allowed, you no longer need to handle abuse from anonymous users at the same rate. If you find out the ticketing system needs strong inventory consistency, you know you cannot use an eventually consistent database for seat reservations.

Domain Entity Identification

After clarifying the domain, identify the core entities, the nouns in the system. Entities become your data models, drive your schema design, and shape your API resources.

For a calendar system:

  • User, an account holder who creates and receives calendar events
  • Event, a point in time with a duration, title, location, and set of attendees
  • RecurrenceRule, an instruction for generating repeated instances of an event (RRULE in iCalendar format)
  • Attendee, a User's participation in an Event (with status: accepted, declined, tentative)
  • Calendar, a named container for events owned by a User

For a ride-sharing platform:

  • Rider, a user requesting a ride
  • Driver, a user providing rides, with a vehicle and real-time location
  • Trip, a completed or in-progress ride from origin to destination
  • MatchRequest, a short-lived entity linking a Rider to available Drivers
  • Location, a geospatial coordinate (latitude/longitude) with a timestamp

For a ticketing system:

  • Event, a concert, game, or show with a date, venue, and seat inventory
  • Venue, a physical location with a configured seat map
  • Seat, a specific position in the Venue with a section, row, and number
  • Reservation, a temporary hold on one or more Seats, with an expiry time
  • Ticket, a confirmed, paid purchase of one or more Seats
  • Order, a transaction grouping multiple Tickets with a payment record

The entity list tells you what tables or document types you need, what the most important queries will be, and where the domain's complexity lives. A calendar system's complexity is in recurring event generation. A ride-sharing system's complexity is in real-time matching and geospatial indexing. A ticketing system's complexity is in preventing double-booking under high concurrency.

Business Constraint Mapping

Every domain imposes constraints that are not obvious from a superficial description. These constraints directly translate to technical requirements.

Regulatory constraints: Payment systems must comply with PCI-DSS (no storing raw card numbers, encrypted transmission). Health data systems must comply with HIPAA (audit logs, encryption at rest, geographic data residency). European users' data may need to stay within EU boundaries (GDPR data residency). In interviews, you do not need to enumerate all regulations, acknowledging that "if this handles payments, we'll need PCI compliance which affects how we store card data" is sufficient.

Geographic constraints: A ride-sharing platform needs geospatial indexing, you cannot find nearby drivers with a standard B-tree database index. You need a spatial data structure like a geohash grid or an R-tree. A global social platform may need to route users to the nearest region for low latency. An e-commerce platform may have different tax and shipping rules by country.

Temporal constraints: A calendar system has timezone complexity, an event at 9 AM EST and 9 AM PST are different absolute times. Recurring events require expansion logic. A ticketing system has time-boxed seat holds, a reservation that expires if payment is not completed within 10 minutes. A flash sale system has a defined start time that creates a thundering herd.

Inventory constraints: Any system that tracks limited resources, seats, hotel rooms, streaming licenses, item stock, has inventory consistency requirements. Double-booking must be prevented. The technical solution depends on whether the window is large (seconds to minutes, database-level locking works) or very small (milliseconds, compare-and-swap atomic operations required).

Read-Heavy vs. Write-Heavy Domain Patterns

Understanding whether a domain is primarily read-heavy or write-heavy changes almost everything about the architecture.

Read-heavy domains: social media feeds (10:1 to 100:1 read:write), URL shorteners (100:1), search queries, product catalogs. Caching is highly effective. Read replicas pay off. Denormalization (duplicating data to avoid joins) is often worth it. Fan-out on write (pre-computing a user's feed when content is published) is common.

Write-heavy domains: event logging, sensor telemetry, real-time analytics, chat messages, audit trails. Append-only architectures work well. LSM-tree based stores (Cassandra, RocksDB) outperform B-tree stores for write throughput. Write-through caching adds overhead without proportional benefit. Batch writes and compaction patterns improve efficiency.

Mixed domains with distinct read and write paths: e-commerce checkout (writes: order creation, payment, inventory decrement; reads: product browsing, search). Separate the write path from the read path using CQRS (Command Query Responsibility Segregation) or event-driven architectures where writes go to one service and read models are computed asynchronously.

Real-Time vs. Batch Domain Patterns

Real-time domains require low-latency, sub-second responses. Ride-sharing location updates must be processed within milliseconds for the matching algorithm to work. Chat messages must be delivered within a second. Live sports score updates cannot be 30 seconds stale. Real-time systems use WebSockets or Server-Sent Events for push delivery, keep connections open, and minimize synchronous processing in the critical path.

Batch domains tolerate high latency. Recommendation systems can compute personalized rankings overnight. Analytics aggregations can run every hour. Report generation can be queued. Batch systems can use cheaper infrastructure (spot instances, lower-priority queues) and process much larger volumes of data per unit time than real-time systems.

Many systems have both: a ride-sharing platform needs real-time location streaming but can batch-compute driver statistics daily. A social platform needs real-time like notifications but can batch-compute weekly engagement reports. Separate these processing modes explicitly in your design, do not use a batch pipeline where you need real-time, and do not over-engineer with real-time infrastructure where batch suffices.

Domain-Specific Data Models

Calendar, recurring events:
Storing every occurrence of a recurring event explicitly (materializing all occurrences) is storage-wasteful and slow to update. Instead, store the recurrence rule (RRULE: FREQ=WEEKLY;BYDAY=MO;COUNT=52) and expand occurrences on read up to a lookahead limit (e.g., 90 days). This means a GET /calendar?from=2026-06-24&to=2026-09-24 request must run the RRULE expansion engine, which has CPU implications at scale.

Ride-sharing, geospatial indexing:
Finding nearby drivers requires a spatial query: "Give me all drivers within 5 km of this coordinate." Standard B-tree indexes on latitude/longitude do not support this efficiently. Solutions:

  • Geohash: encode a (lat, lng) pair into a compact string where nearby points share a common prefix. Query by prefix to find nearby items.
  • H3 (Uber's hexagonal grid): divides the Earth into hexagonal cells at multiple resolutions. Drivers are indexed by cell; nearby cells are enumerated efficiently.
  • PostGIS: a Postgres extension that adds spatial data types and indexes (R-tree). Supports ST_DWithin queries.

Ticketing, inventory reservation:
The core challenge: two users both select seat A7. User 1 checks out and pays. User 2 also pays. Who gets the seat? A naive implementation without locking will double-book.

Pattern: Optimistic reservation with expiry:

  1. When a user selects a seat, create a Reservation record: {seat_id, user_id, expires_at: now + 10min, status: pending}
  2. Mark the seat as held in the seat inventory.
  3. If payment completes before expires_at, promote the Reservation to a Ticket and mark the seat sold.
  4. If payment does not complete, a background job expires the Reservation and marks the seat available again.
  5. Concurrent selection attempts: use a database-level lock or atomic compare-and-swap on the seat's status field.

How Domain Knowledge Shapes NFR Priorities

Different domains prioritize NFRs differently, and understanding this is the mark of a domain-aware engineer:

  • Payment systems: Strong consistency (no double charges), high durability (RPO=0), availability is important but less so than correctness. Uses synchronous replication, two-phase commit for cross-service operations.

  • Social media timelines: High availability (users expect the feed to always load), eventual consistency is fine (a post appearing 1-2 seconds late is acceptable). Uses async fan-out, eventually consistent replication, AP storage.

  • Ride-sharing matching: Ultra-low latency (matching must happen in <1 second), high availability (unavailability means lost revenue), eventual consistency for most data except driver state. Uses in-memory data structures, WebSocket connections, geospatial indexing.

  • Video streaming: High throughput and bandwidth, availability, tolerate stale content metadata. CDN-first delivery, pre-transcoded content, eventual consistency on view counts.

Mermaid Diagram 1: Requirement Clarification Flow

flowchart TD
    A["Receive Problem Statement\n(e.g., 'Design Google Calendar')"]
    B["Understand the Domain\nWhat are the core use cases?\nWhat makes this domain unique?\n'Is recurring event support required?'"]
    C["Identify Entities\nUsers, Events, Attendees, Calendars\nRecurrenceRules, Venues\n'What are the core objects in this system?'"]
    D["Map Relationships\nUser owns many Calendars\nCalendar contains many Events\nEvent has many Attendees\n'How do entities relate to each other?'"]
    E["Clarify Scale\nDAU, QPS, data volume\n'How many calendar events per user per day?'"]
    F["Identify Domain Constraints\nTimezone handling? Recurring events?\nConflict detection? Attendee limits?\n'What makes calendar special vs. generic CRUD?'"]
    G["Define NFR Priorities\nStrong consistency for booking confirmation\nEventual consistency for attendee sync\nLow latency for busy/free queries"]
    H["Begin Design\nWith domain context fully understood"]

    A --> B --> C --> D --> E --> F --> G --> H

Mermaid Diagram 2: Domain-to-Architecture Priority Mapping

graph LR
    Calendar["Calendar System\n(Google Calendar)"]
    RideSharing["Ride-Sharing\n(Uber)"]
    Ecommerce["E-Commerce Ticketing\n(Ticketmaster)"]
    Social["Social Feed\n(Twitter)"]

    CalendarArch["Strong Consistency\nTimezone-Aware Storage\nRRULE Expansion Engine\nConflict Detection"]
    RideArch["Real-Time < 1s\nGeospatial Indexing (H3/Geohash)\nWebSocket Driver Streams\nIn-Memory Location Store"]
    TicketArch["Inventory Locking\nPayment Idempotency\nReservation TTL (10 min)\nDistributed Locking"]
    SocialArch["Eventual Consistency\nFan-Out on Write\nTimeline Caching\nHigh Availability (AP)"]

    Calendar --> CalendarArch
    RideSharing --> RideArch
    Ecommerce --> TicketArch
    Social --> SocialArch

Interview Application

Demonstrating Domain Understanding Without Being Told Specifics

Strong candidates do not wait for the interviewer to explain the domain, they demonstrate that they already understand it. When given a ride-sharing problem, they immediately say: "Ride-sharing is fundamentally a real-time geospatial matching problem. The core challenge is: given a rider's location, find the nearest available driver within X seconds, with a match algorithm that optimizes for wait time and driver utilization. This tells me I need real-time location updates from drivers, a geospatial index, and a matching service that runs continuously."

This opening immediately signals domain depth. You do not need to have worked at Uber, you need to have thought about what makes ride-sharing architecturally different from a generic request-response system.

Techniques to demonstrate domain understanding:

  1. Name the core domain constraint immediately: "Calendar's hardest problem is recurring event semantics and timezone conversion."
  2. Connect the domain to a specific component need: "Ticketing's inventory consistency requirement means I cannot use an eventually consistent database for seat state."
  3. Reference real-world implementations: "Uber uses H3 hexagonal grids for their geospatial indexing, I'll use a similar approach."

Asking Clarifying Questions That Show Depth

Shallow questions: "How many users does the system have?" "What is the scale?"

Deep questions: "For the calendar system, should I support external calendar federation (syncing with Google Calendar or Apple Calendar via CalDAV)? Does event deletion need to cascade to recurring instances, or can individual instances be deleted independently?"

Deep questions reveal that you have thought about edge cases: recurring event exception handling, tombstoning deleted instances, cross-provider synchronization protocols. The interviewer does not need you to solve all of these, they want to see that you know these problems exist.

Pattern for deep clarifying questions: connect the question to a specific implementation decision. "I ask about recurring event exceptions because the answer affects whether I store each exception as an individual event record or as a delta on the master recurrence rule, these have very different storage and query patterns."

Connecting Domain Constraints to Component Choices

Every domain constraint you identify should translate into a specific component decision. This is the direct connection from Step 1 (Problem Framing) to Step 4 (High-Level Design).

Examples:

  • Recurring events require timezone-aware storage → "I'll store all event timestamps in UTC and convert to the user's timezone on read. This avoids the daylight saving time ambiguity of storing local time."
  • Real-time driver locations require sub-second latency → "I'll use an in-memory geospatial index (Redis with Geosearch or a custom H3 hash map) rather than a database query for location lookups."
  • Seat reservations prevent double-booking → "I'll use a database-level row lock (SELECT FOR UPDATE) on the seat record when a user begins checkout, with an application-level TTL to release the lock if payment doesn't complete within 10 minutes."
  • Calendar conflict detection requires efficient free/busy queries → "I'll maintain a separate timeline index, a sorted set of (start_time, end_time, event_id) for each user, so busy/free queries are O(log n) range scans rather than full table scans."

How Domain Knowledge Elevates Problem Framing

Generic problem framing: "I'll build a system that stores events in a database with a cache in front."

Domain-aware problem framing: "Google Calendar has three distinct access patterns: (1) loading a user's calendar view for a date range, high read frequency, needs efficient range queries; (2) creating or editing events, lower write frequency, needs strong consistency for conflict detection; and (3) receiving calendar invites from other users, fan-in pattern, needs eventual consistency for attendee sync. These three patterns have different latency and consistency requirements, which means I may want to separate the write path from the read path."

The domain-aware framing demonstrates that you have thought about the actual usage patterns, not just the data structure. It immediately sets up a richer architectural discussion.

Common Mistakes

Jumping into architecture without understanding the domain. A candidate who immediately draws a database schema for a calendar system before asking about recurring event support will design the wrong schema. Recurring events require fundamentally different storage strategies than one-time events. This mistake costs you later, you discover the mismatch mid-design and have to backtrack awkwardly.

Assuming all systems are read-heavy. Many candidates apply a "high read-to-write ratio" assumption to every system. A financial transaction ledger, a real-time log aggregation pipeline, or an IoT sensor stream are write-heavy. Assuming read-heavy leads to over-caching on the write path and under-investment in write throughput. Always ask about the access pattern.

Ignoring regulatory or geographic constraints. A payment system candidate who designs a database schema that includes raw card numbers has not thought about PCI compliance. A health records candidate who proposes storing patient data in a region without HIPAA compliance fails a critical requirement. You do not need to be a compliance expert, acknowledge that these constraints exist and say you would involve the legal or security team.

Designing a generic system when the interviewer expects domain-specific reasoning. "I'll have a users table, an events table, and a cache" is a generic answer for a calendar system. It misses recurring events, timezone storage, attendee invite flows, and busy/free queries. Generic designs score in the bottom quartile for experienced candidates.

Not asking about the most domain-specific edge cases. For a ticketing system, not asking about concurrent seat selection means your design may silently allow double-booking. For a calendar system, not asking about recurring events means your schema cannot represent 80% of real calendar events. The domain's edge cases are where the interesting engineering happens, and where the best candidates differentiate themselves.

Key Vocabulary

Domain Entity, A core noun in the business domain that becomes a data model and API resource. In interviews: "The core domain entities for a ride-sharing system are Rider, Driver, Trip, and MatchRequest, each maps to a distinct table and has distinct lifecycle states."

Business Constraint, A rule imposed by the domain's business context that restricts system behavior. In interviews: "A key business constraint for ticketing is that a seat can only be sold once, preventing double-booking is the primary consistency requirement."

Requirement Clarification, The process of asking targeted questions to understand the domain's functional scope, scale, and constraints before designing. In interviews: "Before drawing anything, I want to clarify, does the calendar need to support recurring events? Does it need timezone-aware scheduling for international attendees?"

Read-Heavy, A system where reads vastly outnumber writes. Typical ratio is 10:1 to 100:1. In interviews: "URL shorteners are extremely read-heavy, 100:1 or more. That justifies a large cache layer and read replicas."

Write-Heavy, A system where writes are the dominant operation, or where write throughput is the primary scaling challenge. In interviews: "IoT sensor telemetry is write-heavy, millions of sensors sending data every second. That's why we use an append-only store like Cassandra rather than a relational database."

Regulatory Constraint, A legal or compliance requirement that restricts how data is stored, accessed, or processed. In interviews: "If this system handles payment card data, we need to discuss PCI-DSS compliance, specifically, we cannot store raw card numbers; we tokenize at the API gateway using a PCI-compliant vault."

Domain Model, The set of entities, their attributes, and their relationships that collectively represent the problem domain. In interviews: "The domain model for a calendar has three key relationships: User → Calendar (owns), Calendar → Event (contains), Event → User (attendees join)."

Bounded Context, From Domain-Driven Design: a logical boundary within which a particular domain model applies consistently. Useful for explaining microservice decomposition. In interviews: "I'd split this into two bounded contexts: the Scheduling context (events, recurrence, conflict detection) and the Notification context (reminders, attendee invites), they have different consistency requirements and scale independently."

Event-Driven, An architectural pattern where components communicate by producing and consuming events, rather than by direct synchronous calls. In interviews: "When a new event is created on the calendar, I'll publish a CalendarEventCreated event to a queue. The notification service consumes it to send invites, this decouples the creation flow from the notification flow."

Idempotency, The property that performing the same operation multiple times has the same effect as performing it once. Critical for safe retries in distributed systems. In interviews: "For the seat reservation endpoint, I'll require an idempotency key, if the client retries after a timeout, we return the existing reservation rather than creating a duplicate hold."

Summary

Domain knowledge is the final piece of the Fundamentals track because it synthesizes everything that came before. You need system building blocks (System Design Fundamentals) to know what components exist. You need NFRs to understand what properties the domain requires. You need estimation to size the domain's scale. You need API design to express the domain's operations as a clean contract. Domain knowledge ties these together into a coherent, problem-specific design.

The candidates who score highest in system design interviews are not those who have memorized the most diagrams, they are those who, in the first 5 minutes, demonstrate that they understand what makes this problem unique. They ask sharp questions about the domain's most interesting constraints, they name the entities and relationships that shape the data model, and they connect every component choice back to a specific domain requirement.

Every practice problem in Nalar Linuwih is a domain. Before you start designing, spend 5 minutes doing exactly what this lesson teaches: understand the domain, identify the entities, surface the constraints, and use all of that to justify your design decisions. That is what interviewers at top-tier companies look for, and that is what separates a score of 3 from a score of 5 on any system design rubric.

← API Design