A big THANK YOU to everyone who registered and joined the Neutrinos Bounty Challenge: Smart Cache Invalidation for JSON Tree Configs!
We’re thrilled to have such brilliant minds onboard and can’t wait to see the smart solutions you come up with.
The contest is officially LIVE — time to build, design, and deliver!
Reminder: The earlier you finish, the faster we can start evaluating. Once you’re done, please comment below with " Completed " so our team can prioritize your submission for review.
This is your moment to showcase your engineering mojo — so bring your A-game and let’s see who cracks the smartest cache!
I’ve submitted the code with a README in a private GitHub repo and invited you (paul-thomas0) as a collaborator. Let me know if you need anything else.
Hey Everyone. Thank you for your participation in the challenge. To make the competition output fair, we have created a Submission Template to capture the results of suggested features/design/architecture. Please, update the README.md files of your repository with the following template, and add anything else if required for explanation separately.
Tech Stack Used: [Document what technology stack is used.]
Key Components: [Document your application components.]
Subscription Mechanism: [Describe how applications subscribe to the cache store.]
Cache Storage: [Are you using any third-party software components for caching?]
Design Decisions
Why this architecture?
[Explain why you chose this architecture. How do applications subscribe and get notified? When and how do they refresh config on change?]
Trade-offs considered:
[What you optimized for vs. what you sacrificed.]
Performance Test Results
We want to measure how quickly our services pick up configuration changes and how they handle increasing load. Ultimately, we need to know:
Cache-invalidation time: How long each service takes to drop old data and start using the new config.
End-to-end latency: Time from “I changed the config” to “all services have refreshed.”
Scalability: What happens when you add more subscriptions or spin up more services.
Test Configuration
a. Infrastructure
Machines or containers where your services run (e.g. AWS EC2, Docker hosts).
A load generator (e.g. JMeter, Gatling, k6) on a separate machine or container.
b. Service Definitions
Field
Example Value
What It Means
Name
Service A
Unique name for the service.
Instances
1
How many copies you have deployed.
Subscribed To
tenant.service.config.a
Which config paths this service watches.
Tenant
tenantA
Logical group or customer.
Services Setup
Service Name
Instance Count
Subscribed Paths
Tenant
Service A
[1]
[tenant.service.config.a]
[tenantA]
Service B
[1]
[tenant.service.config.b]
[tenantB]
Service C
[N]
[paths…]
[tenant]
Test Scenarios
Scenario
Config Path Changed
Expected Services to Invalidate
Concurrent Requests
1
tenantA.pricing.rules.discount
Service A only
100/sec
2
tenantB.ui.labels.*
Services subscribed to UI
500/sec
Data Collection
a. What to log in each service
Timestamp when the service receives the “invalidate cache” signal.
Timestamp when the service finishes clearing its cache.
Any errors or retries.
Metrics and Calculations
A. Per-Service Cache Invalidation
Metric
Definition
Average (ms)
Mean time between “invalidate received” and “cache cleared.”
Min (ms)
Fastest single invalidation.
Max (ms)
Slowest invalidation—our worst case.
P95 (ms)
95th percentile: 95% of invalidations finish faster than this.
P99 (ms)
99th percentile: critical for spotting outliers.
Below are Markdown-friendly table templates you can copy into any document or spreadsheet. Just fill in the blank rows with your actual test data.
The contest is officially LIVE — time to build, design, and deliver!
Reminder: The earlier you finish, the faster we can start evaluating.
Once you’re done, please comment below with " Completed " so our team can prioritize your submission for review.