Requirements

Let's design a simplified version of Truecaller. Truecaller, at its core, helps users identify unknown callers and provides spam detection. We'll focus on the core features of identifying users and blocking spammers. Imagine you're building this from scratch, focusing on scalability and maintainability. Assume that the user base will grow rapidly. Think about how to design the system to accommodate millions of users and a constantly evolving database of phone numbers. We need to be able to efficiently search for phone numbers, associate them with user information, and quickly identify potential spam callers. # Requirements ## Functional Requirements 1. **User Registration:** * Users should be able to register with their phone number and a name. The system should ensure that each phone number is uniquely associated with a user. * During registration, the system must validate the phone number's format and check for duplicates. 2. **Caller Identification:** * Given a phone number, the system should be able to identify the associated user's name, if registered. * If the phone number is not registered, the system should return "Unknown Caller." 3. **Spam Reporting:** * Users should be able to report a phone number as spam. * The system should track the number of spam reports for each phone number. 4. **Spam Detection:** * The system should automatically detect and flag phone numbers as spam if they exceed a predefined threshold of spam reports. * When a spam number calls, the system should identify it as "Potential Spam." 5. **Contact List:** * Each user can maintain a contact list of other users, identified by their phone numbers. * The system should efficiently retrieve contact information for a user. 6. **Name Suggestion (Community-based):** * If a number is not registered, users can suggest a name for it. These suggestions are tracked along with the number of times they were suggested. * The system identifies a community-suggested name for a number, once a suggestion has reached a minimum number of votes. * If there is a community-suggested name, caller identification should return this name, before the number is registered. 7. **Number Unlisting:** * A user can unlist their number. The system should ensure that unlisted numbers are no longer identifiable via caller identification, unless the calling user has the number in their contact list. ## Non-Functional Requirements 1. **Scalability:** * The system should be able to handle a large number of users and phone numbers. * Caller identification should be fast and efficient, even with millions of phone numbers in the system. 2. **Thread Safety:** * The system must be thread-safe to handle concurrent requests from multiple users, especially during registration, spam reporting, and caller identification. 3. **Extensibility:** * The design should be extensible to accommodate new features, such as advanced spam detection algorithms or integration with other services. 4. **Modularity:** * The system should be modular, with well-defined components and interfaces, to facilitate maintenance and testing. 5. **Testability:** * The design should allow for comprehensive unit and integration testing of all components. 6. **Performance:** * Caller identification should be performed quickly. Optimize data structures and algorithms for speed. 7. **Concurrency:** * Handle concurrent requests efficiently, especially for spam reporting and user registration, to avoid race conditions and ensure data consistency. 8. **Data Consistency:** * Ensure data consistency when updating user profiles, spam reports, and contact lists, especially under concurrent access. Consider using appropriate locking mechanisms or optimistic locking. 9. **Spam Detection Threshold:** * The spam detection threshold should be configurable and easily adjustable to fine-tune spam detection accuracy. ## Core Entities 1. **User:** Represents a registered user in the system. Contains attributes like phone number, name, and contact list. The `User` class must have methods to add and remove contacts. The contact list should be implemented using a suitable data structure for efficient lookups (e.g., a `HashSet`). 2. **PhoneNumber:** A wrapper class representing a phone number. Should include validation logic to ensure the phone number is in a valid format. This class should be immutable. 3. **SpamReport:** Represents a spam report for a phone number. Includes the phone number and the number of reports. 4. **SpamService:** Responsible for managing spam reports and detecting spam numbers. It should maintain a collection of `SpamReport` objects and provide methods to report a number as spam and check if a number is flagged as spam. The `SpamService` should be thread-safe, as multiple users may report spam concurrently. Consider using a `ConcurrentHashMap` to store spam reports. 5. **ContactList:** Manages the contact list for each user. Provides methods to add, remove, and retrieve contacts. Should be optimized for fast lookups. 6. **CallerIdService:** The main service that orchestrates the caller identification process. It uses the `UserService`, `SpamService`, and `CommunitySuggestionService` to identify the caller. 7. **UserService:** Manages user registration and retrieval. It stores user information and provides methods to register a new user, retrieve a user by phone number, and unlist a user's number. Ensure thread-safe access to the user data, possibly using a `ConcurrentHashMap` or other suitable concurrent data structure. 8. **CommunitySuggestionService:** Manages community-suggested names for unregistered phone numbers. It tracks the number of times each name has been suggested and provides a method to retrieve the community-suggested name for a number if it meets the minimum vote threshold. A `ConcurrentHashMap` can store number/suggestion pairs, and an additional data structure can track the vote count for each suggestion. 9. **NameSuggestion:** Represents a name suggestion for a phone number made by the community. It includes the phone number and the suggested name.

Design Truecaller.

Requirements

Interview Simulation

Functional Requirements

💡 Interview Tip

Non-Functional Requirements

Core Entity Identification

Premium Content