Hey Innovators! 
Hope you’re having a great time working on the Neutrinos Bounty Challenge – Smart Cache Invalidation for JSON Tree Configs! 
We know this challenge is stretching your thinking on architecture, performance, and system design — and that’s exactly what makes it so exciting!
Already deep into building? Love it. 
Just getting started? You’ve totally got this! 
Got questions or feeling stuck?
Whether it’s around cache invalidation logic, design trade-offs, testing strategies, or scalability metrics — we’re here to help.
Drop your queries in the comments, and someone from the Neutrinos team or the community will support you.
IMPORTANT REMINDER
Once your solution is ready, make sure to update your repository’s README.md using the official Submission Template below. This helps us evaluate everyone fairly and consistently.
And if you’ve submitted, don’t forget to comment below with “Completed” along with your GitHub repo link — this helps us prioritize your review.
Smart Cache Invalidation Challenge – Submission Template
Participant Information
- Team/Participant Name: [Your Name/Team]
- GitHub Repository: [Link to your implementation]
- Demo Video (optional): [Link to demonstration]
Implementation Overview
- Architecture
- Tech Stack Used
- Key Components
- Subscription Mechanism
- Cache Storage
Design Decisions
- Why this architecture?
- Trade-offs considered
Performance Test Results
Please include:
- Cache-invalidation time
- End-to-end latency
- Scalability under increasing load
Test Configuration
a. Infrastructure
- Where services run (e.g., EC2, Docker)
- Load generator (e.g., JMeter, k6)
b. Service Definitions
| Field | Example Value | What It Means |
|---|---|---|
| Name | Service A | Unique service name |
| Instances | 1 | Number of instances deployed |
| Subscribed To | tenant.service.config.a | Config paths to watch |
| Tenant | tenantA | Logical customer/group |
Service Setup Example
| 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 in Each Service
- Timestamp when cache invalidation signal is received
- Timestamp when cache is cleared
- Errors or retries (if any)
Metrics and Calculations
| Metric | Definition |
|---|---|
| Average (ms) | Mean time to invalidate cache |
| Min (ms) | Fastest cache invalidation |
| Max (ms) | Slowest case observed |
| P95 (ms) | 95% completed within this time |
| P99 (ms) | Useful to identify performance 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.
1. Services Under Test
| Service ID | Service Name | Instances | Tenant | Subscribed Path |
|---|---|---|---|---|
2. Test Scenarios
| Scenario ID | Description | Config Path Changed | Services to Invalidate | Load (req/sec) |
|---|---|---|---|---|
3. Cache Invalidation Log
| Log ID | Run ID | Scenario ID | Service Name | Instance ID | Received Timestamp | Cleared Timestamp | Duration (ms) |
|---|---|---|---|---|---|---|---|
4. End-to-End Metrics
| Run ID | Scenario ID | First Invalidation (ms) | Last Invalidation (ms) | Avg Full Refresh (ms) | Cache Hit Rate (%) |
|---|---|---|---|---|---|
5. Scalability: Subscription Counts
| Run ID | Subscription Count | Avg Invalidation (ms) | Memory Usage (MB) | CPU Usage (%) |
|---|---|---|---|---|
6. Scalability: Service Instances
| Run ID | Service Count | Avg Propagation (ms) | Max Propagation (ms) | Failed Invalidations |
|---|---|---|---|---|
