System requirements

Functional:

• Ability to post an classified ad
• Ability to view and filter classified ads
• Ability to save searches and be notified of new matching ads

Additional functionalities like the ability to bookmark an ad may be considered too, but may be implemented later. Let's keep it in mind while designing the system anyway.

User authentication is also an obvious feature.

Non-Functional:

• Availability: Ability to handle growing load
• User experience: should be nice and fast to keep them engaged
• Resiliency/Fault tolerance: Ability to handle failure on some part of the system
• Consistency: Display accurate search results as well as accurate ad info

Capacity estimation

• 100 000 DAUs
• each user makes about 5 requests per day on average
• 100 000 * 5 => 500 000 requests per day on average
• 500 000 / 86 400 => 6 RPS
• Peak load => Twice average load => 12 RPS
• Concurent users: 10% of DAUs active at given time => 10 000 concurent users

API design

• saveAd(User, title, content, tags, medias) -> Ad ID
• searchAds(search_terms, criterias, notification_frequency, notification_channels) -> Ad list
• NotifyUserOfNewAd(newly_added_ad_id): Async handler, leading to notification in case of match, based on user preferences

Database design

- User: Identifier, login, metadata (name, contact and address if revelant for the system)

Identifier used for sharding (better than login which would imply re-balacing in case of update).

Index should be added on login field at least (retrieve a user) and additional fields based on usage.

- Ad: Identifier, Author (user ID), metadata (title, content, tags, media).

Actual media contents being stored somewhere else like a CDN for fast access (but may be stored on an object storage waiting for kind of validation before being pushed to the CDN).

User ID used as sharding key in order to speed up lookup regarding ads for a specific user.

Index on author may be useful for queries likes displaying every ads for a user.

- Search: Identifier, Author (user ID), search criterias, notification preferences (email and/or push for instance, frequency)

High-level design

• User service: Responsible for user management, storing info as well as authentication
• Ad service: Responsible for managing ads lifecycle 
• Search service: Responsible for search results as well as storing user searches for later notifications
• Notification service: Responsible for notifying the user when new ads are matching theirs saved searches
• Event system: Primarily used for notification purpose, it might eventually be leveraged for other async processing

Each of them except the last one will have their dedicated datastores in order to isolate domains from each others.

It's obvious but system must be elastic enough to be able to setup auto scaling, and using load balancers will helps spreading the traffic among available systems instances.Also, an API gateway will be added as unified entry point for the whole system

Request flows

• Posting ad:
  • User is already authenticated
  • User provide necessary/required info (title, content, optional fields like tags, media, etc) which are sent to Ad service (through API gateway)
  • Ad service perform necessary checks like required fields for instance, banned term, etc. Some of those checks may be done asynchronously to speed up the save process (but will required asynchronous communication back to the user!).
  • Relevant info are store on DB
  • An event is pushed on Event system.
  • Service return the Ad ID in case of success or a comprehensive error to the user (through API Gateway, then converted by the Front-end for user display
• Search:
  • User provides search criteria which are sent to Search service (through API Gateway)
  • Search service provide results, and optionally save the search if asked by the user.
    • Providing results may be intially done through DB queries but may benefits for a dedicated store like ElacticSearch to improve user experience (availability/performance)
  • Results are returned to the API Gateway which gather required info for user display by calling Ad service.
  • Aggregated info are return to the front-end (through API Gateway) which will then display them
• Notification system:
  • Once a new ad is added, Notification system receive an event through Even system
  • It gather necessary info in order to look for saved searches matching the new ad
  • In case of match, the system store in database the info, which are them used by a recurring job in order to notify the user based on its frequency preferences

Detailed component design

Ad service:

1. Posting Logic:
   • Initial Posting: When a user submits an ad, the service should handle the basic required fields (title, content) efficiently to ensure a quick response.
   • Asynchronous Process: After the initial posting, validation checks can be performed asynchronously to avoid blocking the user’s experience.
2. Validation Checks:
   • Basic Validation: Ensure required fields are filled out and simple checks against banned terms.
   • Advanced Validation (later implementation):
     • Fraud Prevention: Implement checks against known patterns of fraudulent ads by leveraging machine learning models or rules.
     • User Ad History: Analyze the user’s past ad behavior to detect anomalies or suspicious activity.
3. Media Handling:
   • Initial Media Upload: Users can upload media which should be temporarily stored (perhaps in object storage) before being pushed to a CDN.
   • URL Generation: The Ad Service needs to generate and return the correct CDN URL for the media rather than a local reference.
   • Deeper Media Analysis (later implementation):
     • Use image recognition and content moderation techniques to filter out inappropriate or abnormal media.
4. Asynchronous Notifications:
   • Since validation and media checks occur asynchronously, the Ad Service needs a mechanism to notify users of the acceptance or rejection of their ads and media.
   • This could be implemented through the Notification Service, where users receive updates based on their preferences (email, push notifications).

Trade offs/Tech choices

High availability over strong consistency: NoSQL database like mongoDB would better scale than an SQL DB.

Failure scenarios/bottlenecks

Peak of traffic:

• High posting request volume: System must be ready to scale to handle peaks (service instances and DB shards)
• High search queries volume: Based on the solution choosen (DB query or ElasticSearch for instance) using cache to store references to ads matching highly used criteria may help here
• High ad display volume: Famous/most-display ads may be fully cached on CDN side as static page to avoid recurring processing. Every ad may be stored that way, taking into account the balance between CDN cost versus recurring processing cost. Alternatively, a normalized view for each ad may be constructed in order to avoid multiple calls tied to data aggregation.

Separation of Concern: Thanks to the fact that the three system are independant from each other, they are able to function even if others are down. It might imply eventual consistency in some cases regarding data display to the user.

Future improvements

• Stronger search components: ElasticSearch for instance
• Fraud prevention system: system detecting odd/suspect behavior or ad
• Payment system: Ease user experience by removing actual money from the process
• Delivery system: Also ease user experience