Neutrinos Bounty Challenge: Cache Smarter, Win Bigger!

General Announcements
21

Hi @Eldho
I’m interested

4 Likes
23

Hey, I’m interested.

4 Likes
24

I’ll participate…please add me…Thanks for arranging this event

4 Likes
25

@Eldoh - Please add me there, interested to experience the challenge.

4 Likes
26

Please add me there, interested in the challenge.

4 Likes
27

I’m Interested, Please add me

4 Likes
28

Hey, I’m interested.

4 Likes
29

Interested. Add me in

4 Likes
30

Hi, I am interested. Let’s give a try.

4 Likes
31

I’m Interested, please add me

4 Likes
32

I’m Interested, Please add me

4 Likes
33

I’m interested, Please add me

4 Likes
34

I’m interested, please add me

4 Likes
35

Hey, I’m interested.

4 Likes
36

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.

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: [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.

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
2 Likes
37

I’m interested, Please add me

4 Likes
38

@Sanjay yes please go ahead once you are done please let us know

2 Likes
39

Please add me to this bounty challenge

3 Likes
40

yes you are in , once you are done please let us know in the comments

1 Like