Requirements

Imagine you are building a robust SMS validation system for a global telecommunications company. This system needs to efficiently and accurately validate SMS messages based on a variety of criteria, including sender ID (short code or phone number), message content (keywords, format), and destination country regulations. The SMS messages will arrive at a high volume, so efficiency and scalability are paramount. We need a flexible architecture that allows adding new validation rules easily and supports different validation strategies for different regions. This is a low-level design problem focusing on the object-oriented design of the SMS validation system. We need to think about how to represent validation rules, how to apply them, and how to manage the validation process in a concurrent environment. We want a system that is easy to extend and maintain as new validation requirements arise. The goal isn't just to validate SMS messages, but to build a well-designed, extensible, and robust system. # Requirements ## Functional Requirements 1. **Validation Rules:** The system must support a variety of validation rules, including: * **Sender ID Validation:** Verify that the sender ID is a valid short code or phone number according to country-specific regulations. This involves checking against whitelists, blacklists, and format requirements. * **Keyword Validation:** Check for the presence or absence of specific keywords in the message content. This can be used for compliance or routing purposes. * **Content Length Validation:** Ensure that the message content adheres to length restrictions, taking into account character encoding (e.g., GSM, UTF-16). * **Regex Validation:** Allow defining validation rules based on regular expressions for more complex pattern matching in the message content. * **Country Specific Validation:** Implement validation rules specific to a destination country (e.g., restrictions on certain keywords, content length limits). * **Opt-out Validation**: Ensure that messages are not being sent to users who have opted out of receiving SMS. * **Time-based Validation**: Implement rules based on time (e.g., preventing sending messages during certain hours). 2. **Rule Management:** The system should provide a mechanism to: * Add new validation rules. * Update existing validation rules. * Remove validation rules. * Prioritize validation rules (e.g., some rules must be checked before others). * Group rules into sets that can be applied to specific SMS messages. 3. **Validation Process:** * Receive an SMS message as input, containing sender ID, destination number, message content, and destination country code. * Apply the appropriate set of validation rules to the SMS message based on pre-defined criteria (e.g., destination country). * Return a validation result indicating whether the SMS message is valid or invalid, and if invalid, provide a list of validation errors. * Support different actions based on the validation results (e.g., forward the SMS message, reject the SMS message, log the validation error). 4. **Configuration**: The system must be configurable: * Load validation rules from a file or database. * Specify the order in which validation rules are applied. * Configure the actions to take based on validation results. 5. **Metrics & Monitoring**: * Track the number of SMS messages validated. * Track the number of messages that passed/failed validation. * Track the execution time of each validation rule. * Provide metrics for monitoring system performance and identifying potential bottlenecks. ## Non-Functional Requirements 1. **Extensibility:** The system should be easily extensible to support new validation rules and validation strategies without requiring significant code changes. This means applying the Open/Closed Principle. 2. **Modularity:** The system should be designed with clear separation of concerns, allowing individual components to be developed, tested, and maintained independently. 3. **Thread Safety:** The system must be thread-safe to handle concurrent requests from multiple SMS gateways. This requires careful consideration of shared resources and synchronization mechanisms. Aim to minimize locking to avoid performance bottlenecks. 4. **Testability:** The system should be designed to be easily testable, with clear interfaces and dependencies that can be mocked or stubbed out. 5. **Performance:** The validation process should be efficient to minimize latency. Consider caching frequently used data (e.g., sender ID whitelists) to improve performance. Optimize algorithm efficiency to avoid bottlenecks. 6. **Maintainability:** The code should be well-documented and easy to understand, following coding conventions and best practices. SOLID principles must be applied. 7. **Error Handling:** The system should handle errors gracefully and provide informative error messages. 8. **Configuration Management:** The system should support externalized configuration, allowing validation rules and other parameters to be updated without requiring code redeployment. ## Core Entities 1. **SMSMessage:** Represents an SMS message, containing attributes such as sender ID, destination number, message content, and destination country code. 2. **ValidationRule:** Represents a validation rule, defining the criteria for validating an SMS message. Implementations could be: `SenderIdValidationRule`, `KeywordValidationRule`, `ContentLengthValidationRule`, `RegexValidationRule`, `CountrySpecificValidationRule`, `OptOutValidationRule`, `TimeBasedValidationRule`. 3. **ValidationResult:** Represents the result of validating an SMS message, indicating whether it is valid or invalid and providing a list of validation errors. 4. **Validator:** An interface (or abstract class) defining the contract for validators. 5. **SMSValidator:** Orchestrates the validation process. It is responsible for applying the appropriate validation rules to an SMS message and returning a validation result. 6. **ValidationError:** Represents a validation error, containing information about the error code, description, and the specific validation rule that failed. 7. **RuleSet:** A group of validation rules. This can be used to apply different sets of rules to different SMS messages based on criteria such as destination country. 8. **RuleSetProvider**: Provides the appropriate `RuleSet` for a given `SMSMessage`. 9. **Cache (Interface):** An optional interface for a cache to avoid repeatedly fetching data (e.g., from a database). Concrete implementations could use in-memory caching (e.g., `HashMap`) or connect to an external cache (e.g., Redis).

Design a SMS validator system.

Requirements

Interview Simulation

Functional Requirements

💡 Interview Tip

Non-Functional Requirements

Core Entity Identification

Premium Content