Search, Notifications, Chat, Fraud Detection & Workflows — Interview Questions

How to use this lesson

Each of these is a classic "design X" prompt. The patterns repeat:

• separate write models from search/read models (CDC into a search index);
• asynchronous fan-out (queues for notifications);
• stateful connections (WebSockets for chat);
• layered decisioning (rules plus ML for fraud);
• explicit state machines (workflows).

Q1. Design a high-scale search system (for example, hotel search).

Short answer:

• Requirements: filter by location (geo), dates, guests, price, amenities and rating; sort by relevance, price or distance; p95 under 300 ms; availability and price must be accurate enough.
• Architecture:
  • Elasticsearch/OpenSearch holds the hotel content and attributes (name, geo point, amenities, rating, popularity);
  • availability and prices change constantly, so they come from the rate cache (Redis), queried for the candidate set, or kept as a coarse "min price per date" field in the index, updated asynchronously;
  • two-phase search: (1) the search engine returns about 200 candidate hotels matching the static filters and geo, ranked by relevance; (2) the availability and pricing service enriches and filters them for the dates, then the final sort and pagination.
• Scale:
  • shards and replicas (replicas scale reads);
  • routing by region;
  • result caching for popular queries (city + dates);
  • search_after for deep pagination instead of large from offsets.
• Relevance: BM25 plus boosts (rating, conversion, distance), personalisation; learning-to-rank at a larger scale; A/B testing of ranking changes.
• Keeping the index fresh: see the indexing pipeline in Q3.

Q2. Design scalable search autocomplete.

Short answer:

• Requirements: suggestions (cities, hotels, landmarks) within about 50–100 ms per keystroke, ranked by popularity, tolerant of typos.
• Approaches:
  • Elasticsearch completion suggester (an in-memory FST, very fast prefix lookup), or search_as_you_type / edge n-gram fields with fuzziness for typos;
  • or a trie with the top-K results precomputed per prefix in memory or Redis (sorted sets keyed by prefix), for the absolute lowest latency.
• Ranking: popularity (from search logs, aggregated offline, for example daily), plus personal context (location, recent searches), with manual boosts and a blocklist.
• Client side: debounce keystrokes (about 150 ms), cancel stale requests, and cache prefixes in the browser; the CDN can cache short prefixes.
• Scale: the suggestion data is small and read-only, so replicate it widely (every node holds the full set); update it by rebuilding and swapping (index aliases).

Learn it in depth → Design a Search Autocomplete

Q3. Design a search indexing pipeline.

Short answer:

• Source of truth: relational databases (content, inventory, rates).
• Change capture: CDC (Debezium) or domain events into Kafka. This is more reliable than dual writes from the application.
• Indexer service:
  • consumes the changes, joins or enriches them into a denormalised search document (fetching related data, or maintaining it with a stream processor);
  • writes to Elasticsearch through the bulk API (batched), using upserts keyed by document ID, with the external version (version_type=external) so out-of-order updates don't overwrite newer data.
• Full reindex (mapping changes, analyser updates):
  • build a new index in the background from a snapshot plus the change stream;
  • then atomically switch an alias (hotels → hotels_v8); zero downtime.
• Failure handling: retries, a DLQ for bad documents, indexing lag monitoring, and a periodic consistency check (counts or checksums between the source and the index).
• Near-real-time: the refresh interval (1 second by default) sets the visibility latency; increase it during bulk loads.

Q4. Design a notification service (a notification microservice).

Short answer:

• Channels: email, SMS, push (APNs, FCM), WhatsApp, in-app, webhooks.
• Flow:
  1. producers publish notification requests or domain events (BookingConfirmed) to Kafka;
  2. the notification service resolves the recipients, user preferences and consent (opt-outs, quiet hours, channel priority), the locale, and the template (versioned templates with variables);
  3. it enqueues per-channel delivery tasks (separate queues, so a slow SMS provider doesn't block email);
  4. channel workers call the providers (SES, SendGrid, Twilio, FCM), with retries, backoff and provider failover;
  5. delivery status (sent, delivered, bounced, opened) comes back through provider webhooks, and is stored.
• Guarantees:
  • idempotency (a dedupe key per event, recipient and template), so retries don't send duplicates;
  • rate limits per provider and per user (don't spam);
  • priority (OTPs and booking confirmations before marketing);
  • scheduling (send at a local time).
• Compliance: unsubscribe links, consent records, DND regulations for SMS, and minimal personal data in logs.
• Observability: delivery rates per channel and provider, latency, bounce and complaint rates.

Learn it in depth → Design a Notification Service

Q5. How do you scale guest chat? (A real-time chat system.)

Short answer:

• Connections: clients keep a WebSocket (or SSE plus POST) connection to a chat gateway tier. Each gateway node holds many thousands of connections (non-blocking I/O: Netty, WebFlux, or virtual threads).
• Routing: a presence and connection registry (Redis: user → gateway node) finds where a recipient is connected. Messages are routed through a pub/sub layer (Redis pub/sub, or Kafka topics partitioned by conversation), so any node can deliver to any user.
• Storage: messages are persisted (Cassandra or DynamoDB, partitioned by conversation ID and time-ordered; or PostgreSQL at a moderate scale) before being acknowledged. Clients fetch history with pagination.
• Delivery semantics: client-generated message IDs (idempotency), per-conversation sequence numbers for ordering, acknowledgements (delivered, read receipts), and offline delivery through push notifications.
• Scale and resilience:
  • horizontally scaled gateways behind a load balancer that supports WebSockets;
  • reconnect with backoff and resume from the last sequence number;
  • graceful draining on deploys;
  • rate limits per user.
• Hotel specifics: routing to staff queues by property and department, SLA timers, handover between an AI assistant and human agents, and translation.

Learn it in depth → Design WhatsApp

Q6. How does an AI chat interact with the backend? Design an AI chat system and its orchestration backend.

Short answer:

• The orchestration service (for example, Spring AI or LangChain4j) sits between the chat UI and the LLM:
  1. receives the user message, with the conversation ID and user context (authenticated guest, booking);
  2. loads the conversation memory (recent turns, summarised), and applies input guardrails (prompt-injection checks, personal-data redaction, topic limits);
  3. retrieves knowledge (RAG): hotel policies, FAQs and amenities from a vector store, filtered by hotel and tenant;
  4. calls the LLM with a system prompt, context and tool definitions;
  5. when the model requests a tool call (getBooking, checkAvailability, createServiceRequest), the orchestrator executes it against the backend APIs with the user's own permissions, validates the arguments, and returns the results to the model;
  6. output guardrails (policy checks, grounding, formatting), then streams the response (SSE or WebSocket);
  7. escalates to a human agent on low confidence, sensitive requests, or on request.
• Non-functional needs:
  • latency (streaming, caching of frequent answers);
  • cost control (model routing: a small model for simple intents, token budgets);
  • rate limits; fallbacks when the LLM provider fails;
  • observability (prompts, tool calls, token usage and latency, with personal data redacted);
  • evaluation (offline test sets, and user feedback);
  • safety: the LLM never gets direct database access, and side-effecting actions need confirmation.

Q7. How do you prevent fraudulent bookings? Design a fraud detection system (and a fraud detection rule system).

Short answer:

• Signals:
  • payment signals (card BIN country versus IP country, AVS or CVV results, 3-D Secure outcome, many cards tried, prepaid cards);
  • velocity (bookings per card, device, IP or email in the last hour);
  • device fingerprinting, disposable emails, behaviour (time on page, copy-pasted data);
  • booking patterns (last-minute high-value stays, many rooms, a mismatched guest name, far-off locations);
  • history (chargebacks, blocklists).
• Architecture:
  1. Real-time scoring in the booking flow (a latency budget of about 50–150 ms): a feature service (velocity counters in Redis, maintained by stream processing), plus a rules engine (explainable, quick to change), plus an ML model (gradient boosting, trained on labelled fraud and chargebacks) produce a risk score.
  2. Decisions: approve; challenge (3-D Secure, OTP, deposit); manual review queue; or decline. Thresholds are tuned per market.
  3. Asynchronous, post-booking analysis: link analysis (shared devices, cards and addresses in graphs), and cancellation of confirmed bookings when fraud is confirmed.
  4. The feedback loop: chargebacks and analyst decisions become labels, for retraining and rule tuning.
• Rule system design:
  • rules as versioned data (a condition over features → a score, or an action);
  • shadow mode for new rules (log what they would have done);
  • rule-performance metrics (precision, recall, false-positive cost);
  • explainability (which rules fired) for analysts;
  • fast rollback.
• Balance: fraud losses against false declines (lost revenue, unhappy guests); measure both.

Q8. How does a BPMN workflow work? Design a complaint and escalation workflow.

Short answer:

• BPMN (Business Process Model and Notation) models processes as start and end events, tasks (service tasks run code; user tasks wait for a human), gateways (decisions, parallel branches), timers and message events. A workflow engine (Camunda, Flowable) executes the model: it persists each process instance's state in a database, waits for events or human input, and resumes, even across restarts. That makes long-running processes (days) reliable and visible.
• The complaint and escalation workflow:
  1. Start: a complaint is received (chat, email, OTA review, front desk), gets a case ID, and is categorised (automatically by rules or ML: cleanliness, billing, noise).
  2. Assign it to a property team queue (a user task), with an SLA timer by severity (for example, 2 hours for a critical one).
  3. Timer boundary events: if not acknowledged or resolved in time, escalate (to the duty manager, then the regional manager), and notify.
  4. A gateway on the outcome: resolved; compensation needed (an approval task above a threshold amount); or transfer to another department.
  5. Guest confirmation (a message event); reopen if the guest isn't satisfied.
  6. End: closed, with a survey; metrics recorded.
• Engineering points:
  • idempotent service tasks (the engine may retry);
  • process versioning (running instances continue on their old version, with migration tools);
  • correlation of external messages to the right instance by business key;
  • dashboards for SLA breaches;
  • audit history per case.
• Alternatives: a simple state machine (Spring Statemachine, or an enum with transition rules plus scheduled SLA checks) for simpler flows; Temporal for code-first durable workflows.

Learn it in depth → State Pattern

Follow-up questions this topic invites — and their answers

Q: Why not query the relational database directly for search? A: Full-text relevance, fuzzy matching, geo queries, faceting and heavy concurrent read traffic are what search engines are built for. Keeping search on a separate read model also protects the transactional database.

Q: How do you avoid sending duplicate notifications? A: Deduplicate with an idempotency key (event ID + recipient + template) stored with a unique constraint or in Redis with a TTL, and make the provider calls idempotent where the provider supports it.

Q: What stops an AI chat assistant from leaking another guest's data? A: Tools run with the authenticated user's permissions, and retrieval is filtered by tenant and user. The model never gets raw database access, and output guardrails check responses. Prompt instructions alone are not a security boundary.

Q: Rules or ML for fraud detection? A: Both. Rules are explainable, immediate and good for known patterns and regulatory needs; ML catches complex and evolving patterns. Scores from ML are usually combined with rules and thresholds.