databricks/dicer
66.7
Adequate · 20 September 2026
49.9k
lines of production code
Scala
primary language
1
measurement over time
What this system is
This system is a distributed caching infrastructure named Dicer, primarily implemented in Scala with comprehensive Java API bindings for broader language support. It provides core caching capabilities including key-based storage, two-level sharding, and target authorization, alongside utilities for consistent hashing and state management. The codebase also includes configuration scaffolding for feature rollouts, infrastructure resource resolution, and internal accessor APIs to support team-specific caching needs.
Features
New Dicer client feature rollout configuration and two-level sharding accessors
This change introduces the core configuration and implementation for Dicer client feature rollouts, allowing features to be enabled or disabled per region and target via \.textproto\ files (including \DicerClientFeatureRolloutConfig\, \DicerClientFeatureRolloutFlag\, and \DicerClientFeatureRolloutRule\). It also adds friend-accessor utilities in \dicer/friend/external\ to support two-level sharding, providing methods to serialize/deserialize secondary slice keys in headers (\TwoLevelShardingHeaders\) and to retrieve resource stubs based on primary and secondary keys (\TwoLevelShardingClerkAccessor\), as well as a low-level accessor for \SliceKey\ deserialization (\SliceKeyAccessor\).
dicer/client/feature-rollouts, dicer/friend/external · high confidence
New Java API bindings for Dicer client and server components
This change introduces a comprehensive Java API layer for the Dicer distributed caching system, providing Java-friendly wrappers for core Scala components. In the \dicer/external/javaapi\ module, new classes such as \Clerk\, \Slicelet\, \Slice\, \SliceKey\, and \Target\ expose the underlying Scala functionality to Java callers, handling type conversions for collections, futures, and options. Configuration is managed via \ClerkConfig\ and \SliceletConfig\ builders, which support TLS options and port overrides. Additionally, \DicerTestEnvironment\ and related builders (\TestAssignmentBuilder\) provide a controlled test environment for Java applications to simulate Dicer behavior, including frozen assignments and slicelet/clerk lifecycle management. The \dicer/client/javaapi\ module adds \ClerkConfImpl\ and \SliceletConfImpl\ to bridge Java configuration needs with the Scala backend, while \caching/util/javaapi\ introduces \TestUtils\ to assist with Java-based test data loading and equality checks.
caching/util/javaapi, dicer/client/javaapi, dicer/external/javaapi · high confidence
New caching utility libraries and test infrastructure
This change introduces a new \caching/util\ module containing reusable Scala utilities for the caching team, including an intrusive min-heap for efficient priority queue operations, a state machine framework for managing asynchronous stateful components, a consistent hash ring for key-to-node mapping, deterministic sampling utilities, HyperLogLog for cardinality estimation, and Prometheus-based error metrics. It also adds a Java API layer with test utilities for loading and validating Protocol Buffer test data, along with the corresponding Bazel build definitions, proto definitions, and test fixtures.
(repo-wide) · high confidence
New friend-accessor APIs for SliceKey, Slice, and Squid
The dicer/friend module now exposes new internal accessors to support the Caching team (Softstore). A new Java API, SliceKeyAccessor, provides a friend method to deserialize SliceKey instances from raw bytes without validation, complementing the existing public validation-based creation methods. Additionally, the Scala SliceAccessor object is introduced to handle conversions between Slice/SliceKey and their corresponding protobuf messages, and a new getSquid method is added to SliceletAccessor to retrieve the underlying Squid instance for a started Slicelet. These changes are restricted to friend-accessible visibility.
dicer/friend · high confidence
OSS Dicer Assigner adds target authorization, migration, and configuration scaffolding
This change introduces the core configuration and authorization scaffolding for the Dicer Assigner in the open-source build. It adds an \Authorizer\ trait and a no-op default implementation to control watch request access, along with metrics to track authorization failures and trusted Clerk requests. It also defines the data models and static providers for target migration (currently fixed to a no-op state) and static target configuration. Additionally, it renames \DicerConfigProvider\ to \DicerSafeConfigProvider\ to align with internal naming, updates the provider to support multiple canary scopes, and adds a test-only factory method. The diff also includes OSS stubs for internal-only components (like JSON conversion and Kam client config) and new wrappers for project configuration, environment detection, and liveness probes.
(repo-wide) · high confidence
Behavioural changes
Demo service keys and configuration simplified
The Dicer demo client and server now use 64-bit (Long) keys instead of 32-bit (Int) keys, changing the cache storage and key hashing logic to support a larger key space. Additionally, the demo services no longer require a Project object for configuration; they now initialize directly with string names ('dicer-demo-client' and 'dicer-demo-server'), and the underlying utility wrappers have been updated to support this simpler initialization pattern while also improving thread naming in executors.
dicer/demo, wrappers/util · high confidence
OSS feature flags now respect static configuration values
In the feature-flag wrapper, the BaseDynamicConf implementation has been updated so that static configuration values are now respected in the open-source edition. Previously, dynamic feature flags always returned their default value regardless of configuration; now, if a static config value is set for a flag name, that value is returned, otherwise the default is used. This change is accompanied by the addition of new utility traits (FlagValueProvider, NamedFlag) and a Java TLS options wrapper (JTLSOptions) in the same location, alongside minor documentation and logging simplifications.
wrappers/feature-flag · high confidence
Refactored debugging server and added infrastructure resource resolution
The local debugging HTTP server has been refactored: the previous singleton \DebugHttpServer\ is removed and replaced by a new \InfoService\ that manages the server lifecycle, registers ZPages and debug endpoints, and supports an optional readiness probe endpoint at \/ready\. The debugging dashboard root handler is now a dedicated \DebuggingRootPageHandler\, and the admin debug URL path has changed from \/debug\ to \/admin/debug\. Additionally, the infrastructure data model now supports regions alongside Kubernetes clusters, introducing \InfraResource\ types and a \ResourcePath\ utility to resolve URIs to specific infrastructure resources.
wrappers/deployment, wrappers/instrumentation · high confidence
Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.
How this codebase got here
Baseline
- First survey — no prior run to compare against. CAI 67.
Lenses
- Code Health 93
- Architecture 97
- Maturity 71
- Readiness 52
- Security 82
Changes since last survey
- 9 commits — 9 feature/other, 0 fixes
By area
- dicer/assigner — 5 commits
- site/.nojekyll — 2 commits
- caching/util — 1 commit
- site/css — 1 commit
Notable commits
- change: Add project landing page under site/
- change: Center nav items with the GitHub button
- change: Project import generated by Copybara
- change: Project import generated by Copybara.
- change: Project import generated by Copybara.
- change: Project import generated by Copybara.
- change: Project import generated by Copybara.
- change: Project import generated by Copybara.
- change: Remove site/ from master
Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.
Survey your own repository
databricks/dicer was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.
About this page
- The score is its most recent published measurement, taken on 20 September 2026 at a pinned commit. It is not a live figure and does not change until the project is measured again.
- Measured at commit d3b73f07269e565ae802d69b95cf7624fcfb746b — the exact code this score is about.
- Scored under rubric-2026.09.15 — the same rubric and the same method as every other entry in this index.
- Measured by watchdog.canine.dev using codehealth-analyzer preprod-b51f968c9b10.