Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Data Model #182

Open
4 of 6 tasks
alexsnaps opened this issue Jun 1, 2023 · 0 comments
Open
4 of 6 tasks

Data Model #182

alexsnaps opened this issue Jun 1, 2023 · 0 comments
Assignees
Labels
kind/epic status/discussing Further information is requested

Comments

@alexsnaps
Copy link
Member

alexsnaps commented Jun 1, 2023

The current data model

The data model resides in the limitador crate source and is broken down into these few structs: Namespace, Limit and finally Counter.

  • Namespace is just a type alias for String and mostly represents a hostname for which limits will be applied
  • Limit is the representation of the definition of a limit: its targeted Namespace, the maximum value for a given time window and a set of conditions. Additionally counters can be qualified using “variables”, e.g. a counter per user identifier. A Limit can be “named” mostly for tracing/debugging purposes.
  • Counters are the actual counters for a limit, e.g. for a given user identifier. It also holds the time-to-live (TTL) for the counter, e.g. the counter should be reset in 32 seconds as the time window would have expired by then.

Interestingly these types fulfill different roles and are closer to Data Transfer Objects (DTOs) than an actual data model. Counters are mostly used as a lookup mechanism to their actual values. In the memory store, the actual values are held in the InMemoryStorage.counters’ TtlCache, that cache is also responsible for applying the correct TTL. Redis is responsible for the same TTL enforcement and stores the values as plain integers in a Hash, keyed by Counter. Limits are too mostly used to look Counters up. They are also used as DTOs for the REST API exposed by the server, e.g. when querying for known counters.

Note: The RocksDbStorage is slightly different as the underlying RocksDB doesn’t have built-in TTL support. That feature was built in an ExpiringValue type that handles the expiry explicitly, while holding the current counter’s value.

Things to address

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/epic status/discussing Further information is requested
Projects
Status: In Progress
Status: In Progress
Development

No branches or pull requests

2 participants