Katkat
Back

Design RSS Feed and Temporary Mail

ConfluentSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

This question tests the ability to design a dual-purpose system that handles high-throughput asynchronous feed ingestion and transient, short-lived email alias management.

System Design: RSS Aggregator & Temporary Email Service

Design a unified platform that provides two primary services: an RSS Aggregator that tracks user-subscribed feeds and a Temporary Email Service that allows users to create short-lived aliases for privacy.

Requirements

RSS Aggregator:

  • Users subscribe to various RSS/Atom feeds.
  • The system must fetch updates periodically and notify users of new content.
  • Assume 100,000 active users with an average of 50 subscriptions each.

Temporary Email Service:

  • Users can generate random email aliases (e.g., [email protected]) that forward to their real inbox.
  • Aliases must have a configurable time-to-live (TTL) after which they are deleted.
  • The system must prevent spam and handle high volumes of incoming mail for aliases.

Expectations

Provide an architectural overview that addresses:

  1. Data Model: Schema choices for feeds, subscription mapping, and ephemeral email aliases.
  2. RSS Ingestion Pipeline: How to handle fetching at scale without overloading source servers or your own system.
  3. Email Handling: Architecture for receiving, routing, and filtering incoming mail to protect against abuse.
  4. Storage/Cache: Strategy for storing historical feed items vs. transient alias states.
  5. Scalability: How the system handles spikes in feed updates or incoming mail bursts.

Hints

Hint 1

Use a distributed task queue (like Kafka or RabbitMQ) to decouple the feed-fetching process from the client notification service.

Hint 2

For temporary emails, utilize a fast, memory-backed storage like Redis with native TTL support to handle automatic expiry.

Hint 3

Implement an exponential backoff strategy for feed fetching to handle sites that publish updates infrequently or sites that are temporarily down.

Follow-up questions

  • How would you handle deduplication if a feed publishes the same content with slightly different timestamps?
  • If the temporary email service becomes a target for spammers, what mechanisms (e.g., rate limiting, reputation scoring) would you implement?
  • How would you ensure the RSS aggregator remains performant if a single feed suddenly has 10,000 items published simultaneously?