[Design Doc] Feature flag backend

[vikhyat187]

Problem	Context	Requirements	API endpoints	Data model	Tech choices	Assumptions	Scale being supported

Problem:

• https://github.com/Real-Dev-Squad/todo-action-items/issues/27

Context:

• This design doc is for the backend of feature-flag-service
• Feature flags are used to enable a feature for a set of users.

Requirements

• Super user can enable or disable feature flag from dashboard-site
• Feature flag is used to release a feature for a set of users
• It should scalable, to be used across all services of RDS.
• It should have fast data access.

API Endpoints:

API contracts: https://github.com/Real-Dev-Squad/feature-flag-backend/blob/develop/openapi.yaml

• GET /feature-flags to get all the feature flags
• POST /feature-flags to create a feature flag
• GET /feature-flags/{flagId} to get the feature flag with Id
• PATCH /feature-flags/{flagId} to update a feature flag
• GET /users/{userId}/feature-flags/{flagId} get a feature flag details for a user
• GET /users/{userId}/feature-flags/ get all feature flag details for a user
• POST /users/{userId}/feature-flags/{flagId} create a feature flag for a user
• PATCH /users/{userId}/feature-flags/{flagId} update a feature flag for a user

Data Model

ER diagram: https://github.com/Real-Dev-Squad/feature-flag-backend/blob/develop/ER%20diagram.jpg

The database being choosed is DynamoDB

FeatureFlag

• Id -> string
• name -> string
• description -> string
• status (At feature flag level) -> string (ENABLED)
• createdAt -> number
• createdBy -> string
• updatedAt -> number
• updatedBy -> string

Partition Key = Id

Sort Key = createdAt (to sort based on creation time)

FeatureFlag-UserMapping

• flagId -> string
• userId -> string
• status -> string (ENABLED, DISABLED) (At User level)
• createdBy -> string
• createdAt -> number
• updatedBy -> string
• updatedAt -> number

---

[RFC] The primary and sort key for FF-User mapping table to be finalised

Partition Key = flagId

Sort key = userId

Technology choices:

• We are going with GoLang for backend implementation.
• For deployment we are going for serverless, considering we may not require it to run on a dedicated virtual server, we can change this later.
• Deployment using Github workflows.

Assumptions

• The design assumes that, the system will be deployed on cloud based serverless infrastructure like AWS Lambda.
• The service will be highly available.
• The max memory, max latency will not be exceeding during the normal operation of application.
• The min memory allocated for lambda will be 128MB.

Scale being supported

AWS Lambda allows you to configure the invocation rate of a Lambda function, which is the rate at which events are sent to the Lambda function for processing. The default invocation rate limit is 1000 requests per second (RPS) per region per AWS account.

Project board: https://github.com/orgs/Real-Dev-Squad/projects/23

Listing all the tasks which have to be done for feature flag implementation.

• [x] Creating tables in AWS. (Feature flag and Feature Flag User Mapping) (1 day)
• [x] Creating a basic SAM template and connecting to AWS. (2 days)
• [x] Creating API endpoint for healthcheck and writing test for the same(1 day + 1-day buffer)
• [ ] Setup DynamoDB Local (1 day + 1 day buffer)
• [ ] Writing test (3 days) Need to learn writing tests
• [ ] Creating API endpoints for /feature-flag (3 days) API Endpoints
• [ ] Creating API endpoints for Feature flag user mapping (3 days + 1-day buffer)
• [ ] Deploying to staging
• [ ] Deploying to prod
• [ ] Post-deployment verification
• [ ] Should we setup cost monitoring for this @ankushdharkar?

Have given the timings considering the average time (around 1.5 to 2hrs every day in RDS) The rough ETA considering the tasks would be around 8th may for all coding tasks and 12th may for go live date.

[gauravv-dev]

The purpose of the design doc is to document all the decision decisions. So ideally I feel there should be these sections

• Problem/Context of the design doc
• Requirements (link the PRD if that exists)
• API Endpoints
• Data model
• Technology choices - All options we considered with pros and cons and why we chose what we chose
• A design diagram that shows all the components and their interactions.

[gauravv-dev]

good job breaking down the tasks though. 👍

[vikhyat187]

The purpose of the design doc is to document all the decision decisions. So ideally I feel there should be these sections

• Problem/Context of the design doc
• Requirements (link the PRD if that exists)
• API Endpoints
• Data model
• Technology choices - All options we considered with pros and cons and why we chose what we chose
• A design diagram that shows all the components and their interactions.

Have made the changes to the doc @dev-gv.

[gauravv-dev]

Also list

• assumptions
• what kind of scale you're designing the solution for. some numbers that the system can support.

[vikhyat187]

done added @dev-gv.

[iamitprakash]

Why updatedAt and createdAt both are numbers datatype, i think you are trying to store datetime stamp

[iamitprakash]

don't we have string length (max char capacity) defined, if you are thinking to keep max, this will lead issues in future while you will have huge data and you will try to do some kind of optimisation

[vikhyat187]

Why updatedAt and createdAt both are numbers datatype, i think you are trying to store datetime stamp

We have use epoch timestamp at other places, so using the same here.

[vikhyat187]

don't we have string length (max char capacity) defined, if you are thinking to keep max, this will lead issues in future while you will have huge data and you will try to do some kind of optimisation

We have checked Dynamodb doesn't allow to set a max size for the attribute.