Submissions for Data Stores track
Guide on how to select datastores to solve different problems
This is a call for Submissions for the Data Stores conferences that will be held between September 2021 and August 2022 for the Data Stores track under Rootconf. Choosing Datastores conferences aim to help technology practitioners learn about how to select a datastore and be aware of their limitations when applied to the problem at hand.
We are accepting experiential talks on:
- Hidden criteria of database selection such as operations or impact on other teams within an organization such as data platform teams.
- Data modelling and developer experience with datastore.
- Running datastores at scale - the true meaning of tuning, debugging and operations.
- Solving specific use cases with a certain datastore.
- DatastoreOps workflows.
- Use of datastore in novel ways to solve for legal regulations.
We invite engineers who work closely with datastores to speak about their experience in selecting, using and scaling these technologies.
About Rootconf
Rootconf is a community funded organization. If you like the work that Rootconf does and want to support meet-ups and activities - online and in-person - contribute by picking up a membership
Contact information
Join the Rootconf Telegram group at https://t.me/rootconf or follow @rootconf on Twitter.
For inquiries, contact Rootconf at rootconf.editorial@hasgeek.com or call 7676332020.
JM
Jatin K Malik
@jatinkrmalik
Optimising configurations @ Uber with dual store strategy
Submitted Aug 18, 2021
Category:
30 min talk
Most of the software services are driven by internal configurations. There is no one-size-fits-all solution for these configurations as they could be as simple as some basic flags to full-blown multi-page JSONs. One common pitfall across these services is that the configurations are hardcoded in the codebase as JSON, YAML files. Customizations are hard to maintain, difficult to change, and prohibitive for cross-team collaboration as they require re-deployment on the codebase for each update.
CO-Configurator acts as a centralized self-service platform with a dual storage mechanism. We get nanoseconds read latency with eventually consistent writes v/s reads over the network. This allows for a best of both worlds scenario based on the downstream service’s requirements and SLAs by also utilizing kafka notification bus to maintain the bookkeeping for all CRUD ops across configurations.
This helps us ensure a reliable experience across the Uber scale.
{{ gettext('Login to leave a comment') }}
{{ gettext('Post a comment…') }}{{ errorMsg }}
{{ gettext('No comments posted yet') }}