Tag Service

gistfile1.txt

Tags: 

tag,hot-lead,null,null,null,hot-lead,hot-lead,tag#deal#2022-05-01,tag,hot-lead,"Hot Lead",tag-uuid-1,1,null,true,2022-05-01,null,null,deal,{}
tag,hot-lead,null,null,null,hot-lead,hot-lead,tag#customer#2022-05-01,tag,hot-lead,"Hot Lead",tag-uuid-1,1,null,true,2022-05-01,null,null,customer,{}
tag,warm-lead,null,null,null,warm-lead,warm-lead,tag#deal#2022-05-01,tag,warm-lead,"Warm Lead",tag-uuid-1,1,null,true,2022-05-01,null,null,deal,{}
tag,warm-lead,null,null,null,warm-lead,warm-lead,tag#customer#2022-05-01,tag,warm-lead,"Warm Lead",tag-uuid-1,1,null,true,2022-05-01,null,null,customer,{}

IDXPK - recordType (e.g. "entity" | "tag")
IDXSK - tagName
IDXLSI1 - scheduledStart
IDXLSI2 - scheduledEnd
GSI1PK - entityId
GSI1SK  - tagName
GSI2PK - tagName
GSI2SK - recordType#entityType#created - e.g. "entity#deal#2022-05-01"
recordType - "entity" | "tag"
tagName
tagLabel
tagUUID
tenantId
entityId
isActive
created
scheduledStart
scheduledEnd
entityType
metadata

Patterns

- tags by entityId
  - GSI1PK: entityId
  - GSI1SK: tagName

- tagged entities by tag
  - GSI2PK: tagName
  - GSI2SK: entityType#created (e.g. "DEAL#2022-05-01))

- tagged entities by multi-tag
  - PK: recordType = 'entity' (e.g. recordType)
  - SK: tagName (#PK = :entityConst AND (#SK = :tag1 AND #SK = :tag2 AND #SK = :tag3))

- tags by entity type
  - PK: entityType
  - SK: tagName

- entities by schedule start
  - PK: recordType = 'entity'
  - SK: scheduledStart 

- entities by schedule end
  - PK: recordType = 'entity'
  - SK: scheduledEnd

tag-service.md

Implementing a Universal Domain Entity Tagging Service

• Status: Proposed
• Deciders: Automatic team
• Date: 2022-05-01

Summary

To support the product feature plans for Automatic and potentially other products, we will need to implement a way to apply system and user-defined tags to domain entities.

Context and Problem Statement

How do we create a backend that will support the need to provide visual cues and flexible categorization of domain objects like vehicles, customers and deals?

It will be beneficial for users to be able to filter lists by tags to view entities that match certain criteria. These tags may in some cases be applied manually by users, otherwise they may be applied by automated processes based on time intervals or workflow triggers.

Expected Use Cases

• Admin users (or system configuration) will enable creation of system tags with a text label and an ID
• (?) Users can create custom tags as well, partitioned by user or product (tenant)
• Users can apply (and remove) tags to entities manually
• Tags may be restricted to only apply to certain types of entities
• Tags may be applied to an entity, but only become active (or inactive) at some configured interval in the future
• Tags may expire and be removed from an entity automatically after a certain time frame
• The system will automatically apply or remove certain tags based on changes in an entity's state
• The system will suport the following commands and queries:
  • Create tags with optional activation and deactivation delay intervals partitioned by tenant, which is either a user or product (?)
  • Apply a tag to a given entity/tenant combination (or collection)
  • Remove a tag from a given entity/tenant combination (or collection)
  • Search for tags by entity ID
  • Search for tagged entities by tag(s)
  • Search for tags by entity type (to see allowed tags for entity)
  • Search for tagged entities by scheduledStart
  • Search for tagged entities by scheduledEnd

Decision Drivers

• Queries should be performant
• The system should be flexible to enable adding new entity types, tenants, tags easily
• The system should be reactive, allowing the application/removal of tags to trigger other actions

Considered Options

• Serverless tagging service using DynamoDB for persistence and change data capture streams to manage workflows plus a cron-like service to handle scheduled updates
• Tag queries/mutations integrated within the existing API and implemented using Postgres and a normalized relational schema to store tags

Decision Outcome

Chosen option: "{option 1}", because {justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force {force} | … | comes out best (see below)}.

Positive Consequences

• {e.g., improvement of quality attribute satisfaction, follow-up decisions required, …}
• …

Negative Consequences

• {e.g., compromising quality attribute, follow-up decisions required, …}
• …

Pros and Cons of the Options

{option 1}

{example | description | pointer to more information | …}

• Good, because {argument a}
• Good, because {argument b}
• Bad, because {argument c}
• …

{option 2}

{example | description | pointer to more information | …}

• Good, because {argument a}
• Good, because {argument b}
• Bad, because {argument c}
• …

{option 3}

{example | description | pointer to more information | …}

• Good, because {argument a}
• Good, because {argument b}
• Bad, because {argument c}
• …

Links

• {Link type} {Link to ADR}
• …