Requirements

Functional Requirements:

• Allow users to create new tags.
• Allow users to rename or edit existing tags.
• Allow users to delete tags they no longer need.
• Allow users to attach one or more tags to any digital item.
• Support searching for items using one or more tags, and return matching items.
• Support suggesting relevant tags when a user is tagging an item, based on item content analysis, existing tags, or user behavior patterns.
• Normalize tags to ensure consistency, lowercasing, trimming whitespace and mapping synonyms.

Non-Functional Requirements:

List the key non-functional requirements (eg low latency, scalability, reliability, etc.)...

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

The api calls are:

GET for the search function

POST when creating new tags

GET when opening their interface and seeing all the tags

DELETE when deleting a tag

POST when renaming tags

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

From a high level, we start with the client interface, which takes the input and first checks if its valid with a fraud protection and rate limiting server. Then the api gateway takes it and passes it to a load balancer which distributes to a server based on the task. Each server is designed to carry out a specific task. For tasks that might slow down the user, we added a kafka queue which will process the request asynchronously. For search, we use a cache to cache the most recent, expected search results, so that the system does not have to go to the database to find the informaiton.

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

For the 4 server design, we used a microservice where each aspect of the app is split up into its own service. We also use a kafka queue for processing small repetitive tasks so the user will not be slown down. We also use a cache for quickly finding search results.

"The search server handles tag queries. When a user searches by tag, the server checks the cache first for common searches. On a miss it queries the database, returns matching items, and stores the result in cache. For popular tags, results are pre-cached."

"Digital items like images or files are stored in S3 object storage. The database only stores metadata and a reference URL pointing to the S3 location. This keeps the database lightweight and lets S3 handle large file storage cheaply."

"Non-critical tasks like tag normalization, suggestion generation, and search indexing are handled asynchronously via the Kafka queue. Workers process these jobs in the background without slowing down the user."

"Popular tags are cached in Redis with a longer TTL so repeated searches never hit the database. Cache is the first stop for every search request."