Changeset View

Standalone View

Show First 20 Lines • Show All 204 Lines • ▼ Show 20 Lines	attribute {
type = "S"		type = "S"
}		}

attribute {		attribute {
name = "deviceID"		name = "deviceID"
type = "S"		type = "S"
}		}
}		}

		resource "aws_dynamodb_table" "feature-flags" {
		name = "feature-flags"
		hash_key = "platform"
		range_key = "feature"
		billing_mode = "PAY_PER_REQUEST"
		bartekUnsubmitted Not Done Inline Actions What's the motivation for using `PAY_PER_REQUEST` instead of `PROVISIONED`? For other tables, we use provisioned mode and specify read/write capacity. For localstack it doesn't matter anyway but I'm asking in context of AWS deployment. bartek: What's the motivation for using `PAY_PER_REQUEST` instead of `PROVISIONED`? For other tables…
		tomekAuthorUnsubmitted Done Inline Actions Feature flags table will be a lot smaller than other tables, writing to it will be performed rarely and only manually (after new release or when we decide to switch a flag). That means that we expect one write per couple of days which makes even the lowest provisioned capacity a couple of orders of magnitude too high for our needs. Initially, reading is similar: one read per native app start, so at most a couple of reads per hour. In the future, if we decide to change an approach so that we query more frequently, we can change the policy. tomek: Feature flags table will be a lot smaller than other tables, writing to it will be performed…

		attribute {
		name = "platform"
		type = "S"
		}

		attribute {
		name = "feature"
		type = "S"
		}
		}