Skip to content

Commit 64e076d

Browse files
author
Imhoertha Ojior
committed
Update ComplainManagement README.md to follow consistent format with ChatSystem example
1 parent bc9ef95 commit 64e076d

File tree

1 file changed

+172
-0
lines changed
  • schema_design/SchemaExamples/ComplainManagement

1 file changed

+172
-0
lines changed

‎schema_design/SchemaExamples/ComplainManagement/README.md‎

Lines changed: 172 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,172 @@
1+
# Complaint Management System Data Modeling with Amazon DynamoDB
2+
3+
## Overview
4+
5+
This document outlines a use case using DynamoDB as a datastore for a complaint management system that efficiently handles customer complaints, agent interactions, and complaint status tracking. The system allows for creating complaints, tracking communications, managing escalations, and monitoring complaint status changes.
6+
7+
## Key Entities
8+
9+
1. Complaint
10+
2. Communication
11+
3. Customer
12+
4. Agent
13+
14+
## Design Approach
15+
16+
We employ a single-table design with a composite primary key and multiple Global Secondary Indexes (GSIs) to support various access patterns.
17+
18+
The following key structures are used:
19+
20+
- Base table
21+
- For a complaint item:
22+
- Partition key (PK)
23+
- Complaint ID (e.g., "Complaint123")
24+
- Sort key (SK)
25+
- "metadata" for complaint details
26+
- For a communication item:
27+
- Partition key (PK)
28+
- Complaint ID (e.g., "Complaint123")
29+
- Sort key (SK)
30+
- "comm#[timestamp]#[comm_id]" for communications
31+
32+
- Examples:
33+
34+
| PK | SK | Sample Attributes |
35+
| ----------- | ----------- | ----------- |
36+
| Complaint123 | metadata | customer_id, severity, complaint_description, current_state |
37+
| Complaint123 | comm#2023-05-01T14:30:00Z#comm456 | agentID, comm_text, complaint_state |
38+
39+
- Global Secondary Indexes:
40+
41+
1. **Customer_Complaint_GSI**
42+
- Partition key: customer_id
43+
- Sort key: complaint_id
44+
45+
- Example:
46+
47+
| customer_id | complaint_id | Sample Attributes |
48+
| ----------- | ----------- | ----------- |
49+
| custXYZ | Complaint123 | PK, SK, severity, current_state |
50+
51+
2. **Escalations_GSI**
52+
- Partition key: escalated_to
53+
- Sort key: escalation_time
54+
55+
- Example:
56+
57+
| escalated_to | escalation_time | Sample Attributes |
58+
| ----------- | ----------- | ----------- |
59+
| AgentB | 2023-05-02T09:15:00Z | PK, SK, severity, customer_id |
60+
61+
3. **Agents_Comments_GSI**
62+
- Partition key: agentID
63+
- Sort key: comm_date
64+
65+
- Example:
66+
67+
| agentID | comm_date | Sample Attributes |
68+
| ----------- | ----------- | ----------- |
69+
| AgentA | 2023-05-01T14:30:00Z | PK, SK, comm_text, complaint_state |
70+
71+
## Access Patterns
72+
73+
The schema design efficiently supports the following access patterns:
74+
75+
| Access pattern | Base table/GSI | Operation | Partition key value | Sort key value | Other conditions/Filters |
76+
| ----------- | ----------- | ----------- | ----------- | ----------- | ----------- |
77+
| Get complaint metadata | Base table | GetItem | PK=\<ComplaintID\> | SK="metadata" | |
78+
| Get all communications for a complaint | Base table | Query | PK=\<ComplaintID\> | begins_with(SK, "comm#") | |
79+
| Get all complaints for a customer | Customer_Complaint_GSI | Query | customer_id=\<CustomerID\> | | |
80+
| Find complaints escalated to an agent | Escalations_GSI | Query | escalated_to=\<AgentID\> | | |
81+
| View agent's communication history | Agents_Comments_GSI | Query | agentID=\<AgentID\> | | |
82+
| Find complaints by severity and state | Base table | Scan | | | Filter on severity and current_state |
83+
| Track complaint state changes | Base table | Query | PK=\<ComplaintID\> | begins_with(SK, "comm#") | Filter on complaint_state changes |
84+
85+
## Data Model Attributes
86+
87+
- **PK**: Partition key - Complaint ID
88+
- **SK**: Sort key - Either "metadata" or communication identifier
89+
- **customer_id**: ID of the customer who filed the complaint
90+
- **complaint_id**: Unique identifier for the complaint
91+
- **comm_id**: Communication identifier
92+
- **comm_date**: Timestamp of the communication
93+
- **complaint_state**: State of the complaint at the time of communication
94+
- **current_state**: Current state of the complaint (waiting, assigned, investigating, resolved)
95+
- **creation_time**: When the complaint was created
96+
- **severity**: Priority level (P1, P2, P3)
97+
- **complaint_description**: Detailed description of the issue
98+
- **comm_text**: Content of the communication
99+
- **attachments**: Set of S3 URLs for attached files
100+
- **agentID**: ID of the agent handling the communication
101+
- **escalated_to**: ID of the agent to whom the complaint was escalated
102+
- **escalation_time**: When the complaint was escalated
103+
104+
## Example Queries
105+
106+
### Get a specific complaint with all its communications
107+
108+
```javascript
109+
// Get complaint metadata
110+
const complaintMetadata = await docClient.get({
111+
TableName: 'Complaint_management_system',
112+
Key: {
113+
PK: 'Complaint123',
114+
SK: 'metadata'
115+
}
116+
}).promise();
117+
118+
// Get all communications for the complaint
119+
const complaintComms = await docClient.query({
120+
TableName: 'Complaint_management_system',
121+
KeyConditionExpression: 'PK = :pk AND begins_with(SK, :sk)',
122+
ExpressionAttributeValues: {
123+
':pk': 'Complaint123',
124+
':sk': 'comm#'
125+
}
126+
}).promise();
127+
```
128+
129+
### Get all complaints for a customer
130+
131+
```javascript
132+
const customerComplaints = await docClient.query({
133+
TableName: 'Complaint_management_system',
134+
IndexName: 'Customer_Complaint_GSI',
135+
KeyConditionExpression: 'customer_id = :custId',
136+
ExpressionAttributeValues: {
137+
':custId': 'custXYZ'
138+
}
139+
}).promise();
140+
```
141+
142+
### Get all escalated complaints for an agent
143+
144+
```javascript
145+
const escalatedComplaints = await docClient.query({
146+
TableName: 'Complaint_management_system',
147+
IndexName: 'Escalations_GSI',
148+
KeyConditionExpression: 'escalated_to = :agentId',
149+
ExpressionAttributeValues: {
150+
':agentId': 'AgentB'
151+
}
152+
}).promise();
153+
```
154+
155+
## Goals
156+
157+
- Efficiently manage customer complaints and related communications
158+
- Track complaint status changes and escalations
159+
- Enable efficient querying by customer, agent, or escalation status
160+
- Ensure scalability using Amazon DynamoDB's single-table design principles
161+
162+
## Schema Design
163+
164+
A comprehensive schema design is included, demonstrating how different entities and access patterns map to the DynamoDB table structure. [ComplaintManagementSchema.json](https://github.com/aws-samples/aws-dynamodb-examples/blob/master/schema_design/SchemaExamples/ComplainManagement/ComplaintManagementSchema.json)
165+
166+
## Design Considerations
167+
168+
1. **Single-Table Design**: All complaint data is stored in a single table to minimize latency and simplify operations.
169+
2. **Chronological Sorting**: Communications are automatically sorted by timestamp due to the SK format.
170+
3. **Flexible Attributes**: The schema accommodates various complaint types and communication formats.
171+
4. **Efficient Querying**: GSIs enable efficient access to data by customer, agent, or escalation status.
172+
5. **Scalability**: The schema is designed to handle a growing number of complaints and communications without performance degradation.

0 commit comments

Comments
 (0)