Design a Real-time Sentiment Analysis Platform — System Design Interview Practice

Interview prompt

Design a real-time sentiment platform that ingests social, review, and support streams, performs multilingual aspect-level analysis, and detects meaningful trend shifts with provenance.

• Define source connectors, deduplication, language detection, sentiment/emotion/aspect outputs, confidence, provenance, and deletion semantics.
• Aggregate results by brand, topic, aspect, geography, and time window while handling bot noise, late events, changing taxonomies, and sampling bias.
• Separate streaming ingestion and model inference from dashboard queries; support model versioning, replay, and at-least-once processing.
• Explain shift alerts, privacy, human review, model fallback, failure recovery, observability, and a degraded mode.

Requirements and scale assumptions

• Ingest authorized posts, reviews, and feedback, normalize and deduplicate them, then classify sentiment, emotion, language, and aspects with confidence.
• Expose near-real-time aggregates, representative evidence, trend charts, and alerts by tenant, brand, topic, aspect, locale, and time window.
• Support source deletion requests, reprocessing with a new model, analyst feedback, alert acknowledgment, and replay after consumer failure.
• Meet p95 end-to-end processing under 2 seconds for sampled events and alert within five minutes of a sustained shift.
• Scale to millions of messages per hour across many brands and languages without unbounded synchronous work.
• Do not lose committed state; make retries and duplicate events safe.
• Degrade safely when downstream workers, caches, or external dependencies fail.
• Millions of messages/hour across many languages
• Partition by the primary tenant, user, item, or geographic key and isolate hot partitions.
• Keep serving state bounded; retain raw events or durable records for replay and auditing.

• Peak scale: 5M messages/hour; 50 languages — Capacity assumption that drives partitioning and backpressure.
• Latency target: p95 processing < 2s; alerts < 5m — User-facing budget for the primary request or read path.
• Durable boundary: Committed before async — Normalized source events and versioned inference results provide replayable provenance.
• Async boundary: At-least-once workers — Keep Fine-tune BERT/RoBERTa for sentiment classification, Use aspect extraction with sequence labeling models, Implement streaming ingestion with Kafka/Pub-Sub off the synchronous path.

Key entities

• DatasetVersiondatasetId, version, schemaHash, qualityStatus, lineage, createdAt

  Immutable real time sentiment analysis platform input version used for reproducible training, evaluation, or replay.

• FeatureSnapshotentityId, featureSetVersion, eventTime, values, sourceWatermarks

  Point-in-time real time sentiment analysis platform features with source watermarks so online and offline values can be compared.

• TrainingRunrunId, datasetVersion, codeVersion, metrics, artifactUri, status

  Audited real time sentiment analysis platform run that records data, code, dependency, and evaluation lineage.

• ModelVersionmodelId, version, stage, schema, qualityGates, endpoint

  A promotable real time sentiment analysis platform model version with rollout state, contract, and rollback metadata.

Data flow

1. 1. Register and validate training dataThe real time sentiment analysis platform gateway records an immutable dataset version, schema, lineage, quality status, and privacy disposition.
2. 2. Build point-in-time featuresFeature workers join real time sentiment analysis platform inputs using event-time watermarks, prevent leakage, and publish the same feature contract for training and serving.
3. 3. Train and evaluate asynchronouslyThe orchestrator schedules real time sentiment analysis platform runs with checkpointed artifacts, reproducible environments, and metrics tied to the exact input versions.
4. 4. Gate and serve a model versionA registry compares real time sentiment analysis platform quality, bias, safety, and compatibility gates before canary or production rollout with an immediate rollback pointer.
5. 5. Monitor drift and learn from feedbackOnline inference records latency, errors, drift, and delayed labels so real time sentiment analysis platform retraining is evidence-driven rather than triggered by guesswork.

Deep dives and trade-offs

• Reproducibility and leakage preventionPin real time sentiment analysis platform data, feature, code, dependency, and model versions for every run. Use point-in-time joins and quarantine failed quality or privacy checks before training. Keep raw inputs and artifacts immutable so a result can be replayed after a dependency changes.
• Safe promotion and serving contractsSeparate real time sentiment analysis platform model registration from deployment and require signed artifacts plus schema compatibility. Use shadow traffic, canaries, rollback pointers, and per-version latency/error budgets. Return model version and feature freshness so clients can explain or reproduce a prediction.
• Drift, feedback, and costMeasure feature drift, prediction drift, label delay, and segment-level quality for real time sentiment analysis platform rather than only aggregate accuracy. Sample expensive inference and cap retraining concurrency with an explicit GPU or compute budget. Keep human corrections and delayed labels linked to the original prediction and model version.
• Batch versus online featuresPrefer a shared feature contract with batch backfills and a low-latency online serving path for decisions that need freshness. Two independently defined transformations create training-serving skew and hard-to-debug regressions.
• Synchronous versus asynchronous inferenceKeep interactive real time sentiment analysis platform inference synchronous within a strict budget and queue large or expensive jobs. A request path that waits for model loading, enrichment, or retraining turns downstream slowness into an outage.
• Global model versus segment modelsStart with one versioned model and add segment-specific models only when quality or policy evidence justifies the operational cost. Many simultaneously active versions multiply monitoring, rollback, and data-lineage burden.