blog-post-slack-move-to-eav#cache-invalidation-at-coarse-grainchanging exactly one workspace preference invalidates that entire cached object blog-post-slack-move-to-eav#cache-invalidation-at-coarse-grain
blog-post-slack-move-to-eav#double-writes-and-backfillMigrating existing data to the new table with double-writes and backfill scripts blog-post-slack-move-to-eav#double-writes-and-backfill
lumping all preferences together made us retrieve a lot of unnecessary information when accessing a single preference
Another strategy would be to create a database table with a column for each preference, so each workspace would have a single row in the table. But as we continue to add more customization for workspaces, this would mean adding new columns to the table — an expensive procedure.
I started with doing "double writes," meaning any time a workspace updated their preferences and updated data in the existing workspaces table, that data was written to the new table
blog-post-slack-move-to-eav#dark-mode1I started with dark mode reads, where any time we want to access workspace prefs, we fetch them from both the existing and the new table. The prefs are compared to catch any inconsistencies, and then the existing data is returned. blog-post-slack-move-to-eav#dark-mode1
blog-post-slack-move-to-eav#light-mode1Once I fixed that bug, and created and ran a backfill script to make the new table consistent with the existing one, it was time for light mode. In light mode, we get the data from the new table and return it instead of ignoring it. I rolled this out slowly, using feature flags to turn on light mode for a few test workspaces, then to our internal Slack, and then finally for all of our users. blog-post-slack-move-to-eav#light-mode1