Bird
Raised Fist0

Design a Job Portal - Search, Candidate Matching, Application Tracking

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/6
API Gateway

Receive job search request

Client sends search query for matching jobs

Protocol:HTTP/REST
BeforeNo active search request in system
AfterSearch request received and parsed by API Gateway
Elasticsearch Cluster

Execute search query

Query jobs and candidates matching criteria

Protocol:Elasticsearch Query
BeforeSearch request forwarded from API Gateway
AfterSearch results retrieved from Elasticsearch index
Kafka Cluster

Publish application event

User applies to a job, event produced to Kafka topic

Protocol:Kafka Produce
BeforeApplication event not yet recorded
AfterApplication event durably stored in Kafka
Application Processing & Notification Service

Consume application event

Process application, update status, trigger notifications

Protocol:Kafka Consume
BeforeApplication event pending processing
AfterApplication status updated; notification prepared
Redis Cluster

Cache notification state

Store notification delivery status for user session

Protocol:Redis GET/SET
BeforeNotification state not cached
AfterNotification state cached for quick retrieval
Apache Cassandra Cluster

Persist application data

Store updated application and candidate info

Protocol:Cassandra Query
BeforeApplication data not updated with latest status
AfterApplication tracking data persisted in Cassandra
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────────────┐
│         API Gateway           │
│  (REST, GraphQL entry point) │
└───────────────┬───────────────┘
                │ HTTP/REST
                ▼
┌───────────────────────────────┐
│ Elasticsearch Cluster         │
│ (Job & Candidate Search Index)│
└───────────────┬───────────────┘
                │ Elasticsearch Query
                ▼
┌───────────────────────────────┐
│ Kafka Cluster                 │
│ (Event streaming queue)       │
└───────────────┬───────────────┘
                │ Kafka Produce
                ▼
┌───────────────────────────────┐
│ Application Processing &      │
│ Notification Service          │
│ (Processes events, sends notif)│
└───────────────┬───────────────┘
                │ Redis GET/SET
                ▼
┌───────────────────────────────┐
│ Redis Cluster                 │
│ (Cache for session & notif)   │
└───────────────┬───────────────┘
                │ Cassandra Query
                ▼
┌───────────────────────────────┐
│ Apache Cassandra Cluster      │
│ (Application & Candidate Data)│
└───────────────────────────────┘
Design Rationale

This architecture shows a vertical flow starting from the API Gateway, which handles client requests. Search queries are routed to the Elasticsearch Cluster for fast retrieval of job and candidate data. When a candidate applies for a job, an event is published to the Kafka Cluster, enabling asynchronous processing. The Application Processing & Notification Service consumes these events to update application status and trigger notifications. Redis is used as a cache to store notification states for quick access, while Apache Cassandra stores persistent application and candidate data. This design decouples components for scalability and responsiveness, using Kafka for event-driven processing and Elasticsearch for efficient search.

Primary Focus

✓

Practice

(1/5)
1. A web application needs to ensure that cache entries are updated immediately after every write to the database to prevent stale reads. Which caching pattern best fits this requirement?
easy
A. Cache Aside, where the application updates the cache only on cache misses
B. Write-Through, where writes go through the cache and update the database synchronously
C. Read-Through, where the cache loads data on reads but writes bypass the cache
D. Write-Behind, where writes are buffered and asynchronously flushed to the database

Solution

  1. Step 1: Identify cache update timing

    Write-Through updates cache and database synchronously, ensuring cache is always fresh.

  2. Step 2: Eliminate other patterns

    Cache Aside updates cache only on misses, risking stale cache after writes; Read-Through only loads on reads; Write-Behind delays DB update, risking stale cache.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Write-Through synchronously updates cache and DB [check]
Hint: Write-Through syncs cache and DB on writes [check]
Common Mistakes:
2. A payment system must ensure that duplicate payment requests from clients do not result in multiple charges. Which component is primarily responsible for handling idempotency in this scenario?
easy
A. The load balancer, by filtering duplicate requests before they reach backend services
B. The database, by enforcing unique constraints on payment amounts and timestamps
C. The client SDK, by retrying requests only once and caching responses locally
D. The transaction processing service, by storing and checking unique request IDs before processing

Solution

  1. Step 1: Identify idempotency enforcement point

    The transaction processing service must track unique request IDs to prevent duplicate charges, as it controls payment execution.

  2. Step 2: Eliminate other options

    The load balancer cannot reliably detect duplicates due to statelessness; the database unique constraints cannot cover all idempotency cases; client SDK retries are unreliable and cannot guarantee global idempotency.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Transaction service stores request IDs -> prevents duplicate processing [check]
Hint: Idempotency enforced where payment logic executes [check]
Common Mistakes:
3. Without a partition-tolerant message queue like Kafka, what exactly breaks in a distributed chat system during a network partition?
medium
A. Alice's send blocks until Bob's server responds -- if Bob's server crashes, message is lost with no retry
B. Messages are duplicated multiple times causing inconsistent chat history
C. Messages are delivered out of order but eventually arrive
D. The system automatically switches to a backup server maintaining availability

Solution

  1. Step 1: Understand role of partition-tolerant queue

    Kafka decouples sender and receiver, buffering messages during partitions.

  2. Step 2: Trace failure without Kafka

    Without Kafka, sender blocks waiting for receiver; if receiver crashes, message is lost with no retry.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Without Kafka, sender blocks and loses messages if receiver crashes [check]
Hint: No Kafka -> sender blocks and loses messages if receiver crashes [check]
Common Mistakes:
4. Without the use of consistent hashing in a distributed cache, what failure scenario occurs when a node is removed?
medium
A. Only the keys assigned to the removed node are lost permanently
B. The system automatically replicates keys to other nodes without delay
C. Clients continue to query the removed node causing request failures
D. All keys must be remapped causing a cache-wide performance degradation and potential cache stampede

Solution

  1. Step 1: Understand modular hashing failure on node removal

    Modular hashing requires remapping all keys, causing performance degradation and cache misses.

  2. Step 2: Evaluate options

    The system automatically replicates keys to other nodes without delay incorrectly assumes automatic replication without delay; Clients continue to query the removed node causing request failures is invalid as clients rely on updated routing.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Without consistent hashing, remapping causes cache stampede, no instant replication [check]
Hint: No consistent hashing -> full remap, cache stampede risk [check]
Common Mistakes:
5. At 10x scale, which component in the AI Code Assistant system is most likely to fail first due to stateful connection limits, and why?
hard
A. The API gateway, because it cannot handle the increased request routing throughput
B. The code generator service, because GPU resources saturate under concurrent requests
C. The WebSocket servers maintaining user sessions, because stateful connections cannot be sharded easily
D. The vector search engine, because its index size grows linearly and slows queries

Solution

  1. Step 1: Analyze vector search scaling

    Vector search scales with index size but can shard horizontally; query latency grows but not immediate failure (A incorrect).

  2. Step 2: Assess code generator scaling

    GPU saturation is a bottleneck but can be mitigated by batching and autoscaling (B less immediate).

  3. Step 3: Evaluate API gateway

    API gateways are stateless and horizontally scalable (C incorrect).

  4. Step 4: Identify WebSocket server bottleneck

    WebSocket servers hold stateful connections bound to server memory; sharding existing connections is complex, causing first failure at 10x scale (D correct).

  5. Final Answer:

    Option C -> Option C

  6. Quick Check:

    Stateful WebSocket connections limit server scaling [check]
Hint: Stateful WebSocket servers bottleneck scaling first [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard