Requirements

Functional Requirements:

List the key functional requirements for the system (Ask the AI for hints if stuck)...

1. Users should be able to create a tag.
2. Users should be able to apply existing tags to various target
3. Users should be able to search items with tags
4. Tags data should be stored for analytics purpose.

Non-Functional Requirements:

List the key non-functional requirements (performance, scalability, reliability, etc.)...

1. Searching SLA should be < 1s
2. Searching API should be available 99%
3. Creating Tag SLA should be < 1s
4. Creating Tag API should be available 99%
5. The system should handle an increasing number of users and tags without a drop in performance
6. Ensuring that tag updates are reflected across all relevant components eventually

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...

There will be 5 major APIs:

Endpoint 1: Create a new tag

POST /tags

• Request Body:
  • display_name (String, required): The displaying name of tag.
• Response:
  • id (String): A unique ID of the tag generated by the system

Endpoint 2: Apply a tag to an entity. Fail if the tag has already been applied to this entity, or if any of the parameter is invalid.

POST /tags/apply

• Request Body:
  • entity_type: (the item type that we're tagging, can be various stuffs in the system, like a user, a payment, or a topic, etc)
  • entity_token: (A unique identifier for that entity within the same type)
  • tag_id: The id of the tag to be applied
• Response:
  • added: A boolean indicating if tag is successfully applied

Endpoint 3: Remove a tag from an entity. Only succeed if the tag has been applied to this entity, and all paramters valid.

DELETE /tags/removeFrom/{entity_type}/{entity_token}/{tag_id}

• Request Body:
  • entity_type: (the item type that we're tagging, can be various stuffs in the system, like a user, a payment, or a topic, etc)
  • entity_token: (A unique identifier for that entity within the same type)
  • tag_id: The id of the tag to be removed
• Response
  • removed: A boolean indicating if tag is successfully removed

Endpoint 4: Remove a tag from the system. Only succeed if the tag id is valid. This will also removed the tag from any entities that have been applied

DELETE /tags/{tag_id}

• Request path:
  • tag_id
• Response Body:
  • Deleted

Endpoint 5: Get all tags applied to an entity

GET /tags/{entity_type}/{entity_token}

• Request Path:
  • entity_type: The type of the entity
  • entity_token: the token of the specific entity
• Response Body:
  • Array of Object:
    • tag_id
    • tag_display_name

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.

As shown in the high level diagram, there are following components in the system

client

TagsWrittingService - handling the write operations, such as creating tags / add tag to an item, etc.

TagsReadingService - handling the read operations, typically fetching all tags added to an item

TagStore: consist of primary and (maybe a number of) replicas. The replication is done asynchronously, therefore the data store is eventual consistent. Write is performed on primary and reads are from replicase.

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.

Storage: The service is reading from replica and writing to primary, and the storage is using an eventual consistent model.

Asynchronous sync: This can be done through eventing