diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
index 28353e61..6652c494 100644
--- a/.github/pull_request_template.md
+++ b/.github/pull_request_template.md
@@ -1,20 +1,30 @@
# 🔁 Pull Request Template – BharatMLStack
-
> Please fill out the following sections to help us review your changes efficiently.
----
+## Context:
+Give a brief overview of the motivation behind this change. Include any relevant discussion links (Slack, documents, tickets, etc.) that help reviewers understand the background and the issue being addressed.
-## 📌 Summary
-
-> e.g., Adds optimizes Redis fetch latency in `online-feature-store`, or improves search UI responsiveness in `trufflebox-ui`.
+## Describe your changes:
+Mention the changes made in the codebase.
----
+## Testing:
+Please describe how you tested the code. If manual tests were performed - please explain how. If automatic tests were added or existing ones cover the change - please explain how did you run them.
-## 📂 Modules Affected
+## Monitoring:
+Explain how this change will be tracked after deployment. Indicate whether current dashboards, alerts, and logs are enough, or if additional instrumentation is required.
-
+## Rollback plan
+Explain rollback plan in case of issues.
+## Checklist before requesting a review
+- [ ] I have reviewed my own changes?
+- [ ] Relevant or critical functionality is covered by tests?
+- [ ] Monitoring needs have been evaluated?
+- [ ] Any necessary documentation updates have been considered?
+
+## 📂 Modules Affected
+
- [ ] `horizon` (Real-time systems / networking)
- [ ] `online-feature-store` (Feature serving infra)
- [ ] `trufflebox-ui` (Admin panel / UI)
@@ -38,5 +48,4 @@
## 📊 Benchmark / Metrics (if applicable)
-
-
+
\ No newline at end of file
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index 76a653ea..ffe4e44c 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -2,9 +2,9 @@ name: Integration & Coordination CI
on:
pull_request:
- branches: [master, develop]
+ branches: [main, develop]
push:
- branches: [master, develop]
+ branches: [main, develop]
workflow_dispatch: # Allow manual triggering
env:
@@ -20,8 +20,8 @@ jobs:
online-feature-store-changed: ${{ steps.changes.outputs.online-feature-store }}
go-sdk-changed: ${{ steps.changes.outputs.go-sdk }}
py-sdk-changed: ${{ steps.changes.outputs.py-sdk }}
- helix-client-changed: ${{ steps.changes.outputs.helix-client }}
inferflow-changed: ${{ steps.changes.outputs.inferflow }}
+ skye-changed: ${{ steps.changes.outputs.skye }}
multiple-components: ${{ steps.check-multiple.outputs.multiple }}
any-component: ${{ steps.check-any.outputs.any }}
steps:
@@ -47,10 +47,10 @@ jobs:
- 'go-sdk/**'
py-sdk:
- 'py-sdk/**'
- helix-client:
- - 'helix-client/**'
inferflow:
- 'inferflow/**'
+ skye:
+ - 'skye/**'
- name: Check if multiple components changed
id: check-multiple
@@ -74,10 +74,10 @@ jobs:
if [ "${{ steps.changes.outputs.py-sdk }}" == "true" ]; then
changed_count=$((changed_count + 1))
fi
- if [ "${{ steps.changes.outputs.helix-client }}" == "true" ]; then
+ if [ "${{ steps.changes.outputs.inferflow }}" == "true" ]; then
changed_count=$((changed_count + 1))
fi
- if [ "${{ steps.changes.outputs.inferflow }}" == "true" ]; then
+ if [ "${{ steps.changes.outputs.skye }}" == "true" ]; then
changed_count=$((changed_count + 1))
fi
@@ -90,7 +90,7 @@ jobs:
- name: Check if any component changed
id: check-any
run: |
- if [ "${{ steps.changes.outputs.horizon }}" == "true" ] || [ "${{ steps.changes.outputs.trufflebox-ui }}" == "true" ] || [ "${{ steps.changes.outputs.numerix }}" == "true" ] || [ "${{ steps.changes.outputs.online-feature-store }}" == "true" ] || [ "${{ steps.changes.outputs.go-sdk }}" == "true" ] || [ "${{ steps.changes.outputs.py-sdk }}" == "true" ] || [ "${{ steps.changes.outputs.helix-client }}" == "true" ] || [ "${{ steps.changes.outputs.inferflow }}" == "true" ]; then
+ if [ "${{ steps.changes.outputs.horizon }}" == "true" ] || [ "${{ steps.changes.outputs.trufflebox-ui }}" == "true" ] || [ "${{ steps.changes.outputs.numerix }}" == "true" ] || [ "${{ steps.changes.outputs.online-feature-store }}" == "true" ] || [ "${{ steps.changes.outputs.go-sdk }}" == "true" ] || [ "${{ steps.changes.outputs.py-sdk }}" == "true" ] || [ "${{ steps.changes.outputs.inferflow }}" == "true" ] || [ "${{ steps.changes.outputs.skye }}" == "true" ]; then
echo "any=true" >> $GITHUB_OUTPUT
else
echo "any=false" >> $GITHUB_OUTPUT
@@ -110,8 +110,8 @@ jobs:
echo "- Online Feature Store CI: ${{ needs.detect-changes.outputs.online-feature-store-changed }}"
echo "- Go SDK CI: ${{ needs.detect-changes.outputs.go-sdk-changed }}"
echo "- Python SDK CI: ${{ needs.detect-changes.outputs.py-sdk-changed }}"
- echo "- Helix Client CI: ${{ needs.detect-changes.outputs.helix-client-changed }}"
echo "- Inferflow CI: ${{ needs.detect-changes.outputs.inferflow-changed }}"
+ echo "- Skye CI: ${{ needs.detect-changes.outputs.skye-changed }}"
echo "This workflow will proceed with integration tests..."
integration-tests:
@@ -130,7 +130,6 @@ jobs:
echo "Testing Numerix matrix operations integration..."
echo "Testing Go SDK compatibility with backend services..."
echo "Testing Python SDK compatibility with backend services..."
- echo "Testing Helix Client compatibility with backend services..."
echo "Testing Inferflow compatibility with backend services..."
# Add actual integration test commands here
@@ -211,5 +210,5 @@ jobs:
echo "- Online Feature Store: ${{ needs.detect-changes.outputs.online-feature-store-changed }}" >> $GITHUB_STEP_SUMMARY
echo "- Go SDK: ${{ needs.detect-changes.outputs.go-sdk-changed }}" >> $GITHUB_STEP_SUMMARY
echo "- Python SDK: ${{ needs.detect-changes.outputs.py-sdk-changed }}" >> $GITHUB_STEP_SUMMARY
- echo "- Helix Client: ${{ needs.detect-changes.outputs.helix-client-changed }}" >> $GITHUB_STEP_SUMMARY
- echo "- Inferflow: ${{ needs.detect-changes.outputs.inferflow-changed }}" >> $GITHUB_STEP_SUMMARY
\ No newline at end of file
+ echo "- Inferflow: ${{ needs.detect-changes.outputs.inferflow-changed }}" >> $GITHUB_STEP_SUMMARY
+ echo "- Skye: ${{ needs.detect-changes.outputs.skye-changed }}" >> $GITHUB_STEP_SUMMARY
\ No newline at end of file
diff --git a/.github/workflows/go-sdk.yml b/.github/workflows/go-sdk.yml
index 1f0bce69..d2356a14 100644
--- a/.github/workflows/go-sdk.yml
+++ b/.github/workflows/go-sdk.yml
@@ -2,10 +2,10 @@ name: Go SDK CI
on:
pull_request:
- branches: [master, develop]
+ branches: [main, develop]
paths: ['go-sdk/**']
push:
- branches: [master, develop]
+ branches: [main, develop]
paths: ['go-sdk/**']
jobs:
diff --git a/.github/workflows/helix-client.yml b/.github/workflows/helix-client.yml
deleted file mode 100644
index 9afb5ba5..00000000
--- a/.github/workflows/helix-client.yml
+++ /dev/null
@@ -1,71 +0,0 @@
-name: Helix Client CI
-
-on:
- pull_request:
- branches: [master, develop]
- paths: ['helix-client/**']
- push:
- branches: [master, develop]
- paths: ['helix-client/**']
-
-jobs:
- build-helix-client:
- runs-on: ubuntu-latest
- defaults:
- run:
- working-directory: ./helix-client
- steps:
- - name: Checkout code
- uses: actions/checkout@v4
-
- - name: Set up Go
- uses: actions/setup-go@v4
- with:
- go-version: '1.24'
- cache: false
-
- - name: Cache Go modules
- uses: actions/cache@v3
- with:
- path: |
- ~/.cache/go-build
- ~/go/pkg/mod
- key: ${{ runner.os }}-helix-client-${{ hashFiles('helix-client/go.sum') }}
- restore-keys: |
- ${{ runner.os }}-helix-client-
-
- - name: Download dependencies
- run: go mod download
-
- - name: Verify dependencies
- run: go mod verify
-
- - name: Run tests
- run: go test -v ./...
-
- - name: Run tests with coverage
- run: go test -v -coverprofile=coverage.out ./...
-
- - name: Display coverage
- run: go tool cover -func=coverage.out
-
- - name: Build SDK packages
- run: go build -v ./...
-
- - name: Run go vet
- run: go vet ./...
-
- - name: Install staticcheck
- run: go install honnef.co/go/tools/cmd/staticcheck@latest
-
- - name: Run staticcheck
- run: staticcheck ./...
-
- - name: Check for go mod tidy
- run: |
- go mod tidy
- if [ -n "$(git status --porcelain go.mod go.sum)" ]; then
- echo "go.mod or go.sum is not tidy"
- git diff go.mod go.sum
- exit 1
- fi
\ No newline at end of file
diff --git a/.github/workflows/horizon.yml b/.github/workflows/horizon.yml
index 33b7497c..a958ed21 100644
--- a/.github/workflows/horizon.yml
+++ b/.github/workflows/horizon.yml
@@ -2,10 +2,10 @@ name: Horizon CI
on:
pull_request:
- branches: [master, develop]
+ branches: [main, develop]
paths: ['horizon/**']
push:
- branches: [master, develop]
+ branches: [main, develop]
paths: ['horizon/**']
jobs:
@@ -21,7 +21,7 @@ jobs:
- name: Set up Go
uses: actions/setup-go@v4
with:
- go-version: '1.23'
+ go-version: '1.24'
cache: false
- name: Cache Go modules
diff --git a/.github/workflows/inferflow.yml b/.github/workflows/inferflow.yml
index bb93e1be..f5c7f22a 100644
--- a/.github/workflows/inferflow.yml
+++ b/.github/workflows/inferflow.yml
@@ -2,10 +2,10 @@ name: Inferflow CI
on:
pull_request:
- branches: [master, develop]
+ branches: [main, develop]
paths: ['inferflow/**']
push:
- branches: [master, develop]
+ branches: [main, develop]
paths: ['inferflow/**']
jobs:
diff --git a/.github/workflows/interaction-store.yml b/.github/workflows/interaction-store.yml
new file mode 100644
index 00000000..eca96afd
--- /dev/null
+++ b/.github/workflows/interaction-store.yml
@@ -0,0 +1,56 @@
+name: Interaction Store CI
+
+on:
+ pull_request:
+ branches: [main, develop]
+ paths: ['interaction-store/**']
+ push:
+ branches: [main, develop]
+ paths: ['interaction-store/**']
+
+jobs:
+ build-interaction-store:
+ runs-on: ubuntu-latest
+ defaults:
+ run:
+ working-directory: ./interaction-store
+ steps:
+ - name: Checkout code
+ uses: actions/checkout@v4
+
+ - name: Set up Go
+ uses: actions/setup-go@v4
+ with:
+ go-version: '1.24'
+ cache: false
+
+ - name: Cache Go modules
+ uses: actions/cache@v3
+ with:
+ path: |
+ ~/.cache/go-build
+ ~/go/pkg/mod
+ key: ${{ runner.os }}-go-is-${{ hashFiles('interaction-store/go.sum') }}
+ restore-keys: |
+ ${{ runner.os }}-go-is-
+
+ - name: Download dependencies
+ run: go mod download
+
+ - name: Run tests
+ run: go test -v ./...
+
+ - name: Build server
+ run: go build -v ./cmd/server
+
+ - name: Build consumer
+ run: go build -v ./cmd/consumer
+
+ - name: Run go vet
+ run: go vet ./...
+
+ - name: Install staticcheck
+ run: go install honnef.co/go/tools/cmd/staticcheck@latest
+
+ - name: Run staticcheck
+ run: staticcheck ./...
diff --git a/.github/workflows/numerix.yml b/.github/workflows/numerix.yml
index b1c6ba89..972dbec3 100644
--- a/.github/workflows/numerix.yml
+++ b/.github/workflows/numerix.yml
@@ -2,10 +2,10 @@ name: Numerix CI
on:
pull_request:
- branches: [master, develop]
+ branches: [main, develop]
paths: ['numerix/**']
push:
- branches: [master, develop]
+ branches: [main, develop]
paths: ['numerix/**']
jobs:
diff --git a/.github/workflows/online-feature-store.yml b/.github/workflows/online-feature-store.yml
index 822baf6a..d5f33d50 100644
--- a/.github/workflows/online-feature-store.yml
+++ b/.github/workflows/online-feature-store.yml
@@ -2,10 +2,10 @@ name: Online Feature Store CI
on:
pull_request:
- branches: [master, develop]
+ branches: [main, develop]
paths: ['online-feature-store/**']
push:
- branches: [master, develop]
+ branches: [main, develop]
paths: ['online-feature-store/**']
jobs:
diff --git a/.github/workflows/py-sdk.yml b/.github/workflows/py-sdk.yml
index 202d3224..799450f2 100644
--- a/.github/workflows/py-sdk.yml
+++ b/.github/workflows/py-sdk.yml
@@ -2,10 +2,10 @@ name: Python SDK CI
on:
pull_request:
- branches: [master, develop]
+ branches: [main, develop]
paths: ['py-sdk/**']
push:
- branches: [master, develop]
+ branches: [main, develop]
paths: ['py-sdk/**']
jobs:
diff --git a/.github/workflows/release-helix-client.yml b/.github/workflows/release-helix-client.yml
deleted file mode 100644
index 5ed33890..00000000
--- a/.github/workflows/release-helix-client.yml
+++ /dev/null
@@ -1,151 +0,0 @@
-name: Release Helix Client
-
-on:
- workflow_dispatch:
- inputs:
- version:
- description: 'Version to release (e.g., v0.1.20 or v0.1.20-beta.1)'
- required: true
- type: string
- is_beta:
- description: 'Is this a beta release?'
- required: false
- type: boolean
- default: false
- is_alpha:
- description: 'Is this an alpha release?'
- required: false
- type: boolean
- default: false
- branch:
- description: 'Branch to release from'
- required: true
- type: string
- default: 'main'
-
-jobs:
- release:
- runs-on: ubuntu-latest
- permissions:
- contents: write
- steps:
- - name: Checkout repository
- uses: actions/checkout@v4
- with:
- fetch-depth: 0
- ref: ${{ inputs.branch }}
-
- - name: Set up Go
- uses: actions/setup-go@v4
- with:
- go-version: '1.24'
-
- - name: Validate Helix Client
- run: |
- echo "Current branch: ${{ github.ref }}"
- cd helix-client
- go mod tidy
- go test -v ./...
- go build -v ./...
- go vet ./...
-
- - name: Create Git tag
- run: |
- git config --global user.name "github-actions[bot]"
- git config --global user.email "41898282+github-actions[bot]@users.noreply.github.com"
-
- TAG="helix-client/${{ inputs.version }}"
- git tag -a "$TAG" -m "Helix Client release ${{ inputs.version }}"
- git push origin "$TAG"
-
- - name: Create GitHub Release (Production)
- if: ${{ !inputs.is_beta && !inputs.is_alpha }}
- uses: actions/create-release@v1
- env:
- GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- with:
- tag_name: helix-client/${{ inputs.version }}
- release_name: Helix Client ${{ inputs.version }}
- body: |
- ## Helix Client Release ${{ inputs.version }}
-
- ### Installation
- ```bash
- go get github.com/${{ github.repository }}/helix-client@${{ inputs.version }}
- ```
-
- ### Features
- - Go client libraries for BharatMLStack services
- - Numerix, Predator, and Skye client integrations
- - Type-safe API bindings and gRPC support
-
- ### Usage
- ```go
- import "github.com/${{ github.repository }}/helix-client"
- ```
-
- ### Changes
- Please see the commit history for detailed changes.
-
- ### Validation
- - ✅ Tests passed
- - ✅ Build successful
- - ✅ Go vet clean
- draft: false
- prerelease: false
-
- - name: Create Beta Pre-release
- if: ${{ inputs.is_beta }}
- uses: actions/create-release@v1
- env:
- GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- with:
- tag_name: helix-client/${{ inputs.version }}
- release_name: Helix Client ${{ inputs.version }} (Beta)
- body: |
- ## Helix Client Beta Release ${{ inputs.version }}
-
- ⚠️ **This is a beta release from the develop branch** - Use for testing purposes only.
-
- ### Installation
- ```bash
- go get github.com/${{ github.repository }}/helix-client@${{ inputs.version }}
- ```
-
- ### Changes
- Please see the commit history for detailed changes.
-
- ### Validation
- - ✅ Tests passed
- - ✅ Build successful
- - ✅ Go vet clean
- draft: false
- prerelease: true
-
- - name: Create Alpha Pre-release
- if: ${{ inputs.is_alpha }}
- uses: actions/create-release@v1
- env:
- GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- with:
- tag_name: helix-client/${{ inputs.version }}
- release_name: Helix Client ${{ inputs.version }} (Alpha)
- body: |
- ## Helix Client Alpha Release ${{ inputs.version }}
-
- ⚠️ **This is an alpha release from a feature/fix branch** - Experimental build for development and testing.
-
- ### Installation
- ```bash
- go get github.com/${{ github.repository }}/helix-client@${{ inputs.version }}
- ```
-
- ### Changes
- Please see the commit history for detailed changes.
-
- ### Validation
- - ✅ Tests passed
- - ✅ Build successful
- - ✅ Go vet clean
- draft: false
- prerelease: true
\ No newline at end of file
diff --git a/.github/workflows/release-interaction-store.yml b/.github/workflows/release-interaction-store.yml
new file mode 100644
index 00000000..b23a220f
--- /dev/null
+++ b/.github/workflows/release-interaction-store.yml
@@ -0,0 +1,166 @@
+name: Release Interaction Store
+
+on:
+ workflow_dispatch:
+ inputs:
+ version:
+ description: 'Version to release (e.g., v0.1.20 or v0.1.20-beta.1)'
+ required: true
+ type: string
+ is_beta:
+ description: 'Is this a beta release?'
+ required: false
+ type: boolean
+ default: false
+ is_alpha:
+ description: 'Is this an alpha release?'
+ required: false
+ type: boolean
+ default: false
+ branch:
+ description: 'Branch to release from'
+ required: true
+ type: string
+ default: 'main'
+
+env:
+ REGISTRY: ghcr.io
+ IMAGE_PREFIX: ghcr.io/${{ github.repository_owner }}
+
+jobs:
+ release:
+ runs-on: ubuntu-latest
+ permissions:
+ contents: write
+ packages: write
+ strategy:
+ matrix:
+ component: [
+ {name: "interaction-store-server", dockerfile: "cmd/server/Dockerfile"},
+ {name: "interaction-store-consumer", dockerfile: "cmd/consumer/Dockerfile"}
+ ]
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v4
+ with:
+ fetch-depth: 0
+ ref: ${{ inputs.branch }}
+
+ - name: Set up Docker Buildx
+ uses: docker/setup-buildx-action@v3
+
+ - name: Log in to Container Registry
+ uses: docker/login-action@v3
+ with:
+ registry: ${{ env.REGISTRY }}
+ username: ${{ github.actor }}
+ password: ${{ secrets.GITHUB_TOKEN }}
+
+ - name: Extract metadata
+ id: meta
+ uses: docker/metadata-action@v5
+ with:
+ images: ${{ env.IMAGE_PREFIX }}/${{ matrix.component.name }}
+ tags: |
+ type=raw,value=${{ inputs.version }}
+ type=raw,value=latest,enable=${{ !inputs.is_beta && !inputs.is_alpha }}
+
+ - name: Build and push Docker image
+ uses: docker/build-push-action@v5
+ with:
+ context: ./interaction-store
+ file: ./interaction-store/${{ matrix.component.dockerfile }}
+ platforms: linux/amd64,linux/arm64
+ push: true
+ tags: ${{ steps.meta.outputs.tags }}
+ labels: ${{ steps.meta.outputs.labels }}
+ cache-from: type=gha
+ cache-to: type=gha,mode=max
+
+ create-release:
+ needs: release
+ runs-on: ubuntu-latest
+ if: ${{ !inputs.is_beta && !inputs.is_alpha }}
+ steps:
+ - name: Create GitHub Release (Production)
+ uses: actions/create-release@v1
+ env:
+ GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+ with:
+ tag_name: interaction-store/${{ inputs.version }}
+ release_name: Interaction Store ${{ inputs.version }}
+ body: |
+ ## Interaction Store Release ${{ inputs.version }}
+
+ ### Docker Images
+ - `${{ env.IMAGE_PREFIX }}/interaction-store-server:${{ inputs.version }}`
+ - `${{ env.IMAGE_PREFIX }}/interaction-store-consumer:${{ inputs.version }}`
+
+ ### Components
+ - **Server**: gRPC API server for interaction store operations
+ - **Consumer**: Kafka consumer for real-time interaction ingestion
+
+ ### Changes
+ Please see the commit history for detailed changes.
+ draft: false
+ prerelease: false
+
+ create-beta-release:
+ needs: release
+ runs-on: ubuntu-latest
+ if: ${{ inputs.is_beta }}
+ steps:
+ - name: Create GitHub Release (Beta)
+ uses: actions/create-release@v1
+ env:
+ GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+ with:
+ tag_name: interaction-store/${{ inputs.version }}
+ release_name: Interaction Store ${{ inputs.version }} (Beta)
+ body: |
+ ## Interaction Store Beta Release ${{ inputs.version }}
+
+ ⚠️ **This is a beta release from the develop branch** - Use for testing purposes only.
+
+ ### Docker Images
+ - `${{ env.IMAGE_PREFIX }}/interaction-store-server:${{ inputs.version }}`
+ - `${{ env.IMAGE_PREFIX }}/interaction-store-consumer:${{ inputs.version }}`
+
+ ### Components
+ - **Server**: gRPC API server for interaction store operations
+ - **Consumer**: Kafka consumer for real-time interaction ingestion
+
+ ### Changes
+ Please see the commit history for detailed changes.
+ draft: false
+ prerelease: true
+
+ create-alpha-release:
+ needs: release
+ runs-on: ubuntu-latest
+ if: ${{ inputs.is_alpha }}
+ steps:
+ - name: Create GitHub Release (Alpha)
+ uses: actions/create-release@v1
+ env:
+ GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+ with:
+ tag_name: interaction-store/${{ inputs.version }}
+ release_name: Interaction Store ${{ inputs.version }} (Alpha)
+ body: |
+ ## Interaction Store Alpha Release ${{ inputs.version }}
+
+ ⚠️ **This is an alpha release from a feature/fix branch** - Experimental build for development and testing.
+
+ ### Docker Images
+ - `${{ env.IMAGE_PREFIX }}/interaction-store-server:${{ inputs.version }}`
+ - `${{ env.IMAGE_PREFIX }}/interaction-store-consumer:${{ inputs.version }}`
+
+ ### Components
+ - **Server**: gRPC API server for interaction store operations
+ - **Consumer**: Kafka consumer for real-time interaction ingestion
+
+ ### Changes
+ Please see the commit history for detailed changes.
+ draft: false
+ prerelease: true
diff --git a/.github/workflows/release-skye.yml b/.github/workflows/release-skye.yml
new file mode 100644
index 00000000..49eee560
--- /dev/null
+++ b/.github/workflows/release-skye.yml
@@ -0,0 +1,186 @@
+name: Release Skye
+
+on:
+ workflow_dispatch:
+ inputs:
+ version:
+ description: 'Version to release (e.g., v0.1.0 or v0.1.0-beta.1)'
+ required: true
+ type: string
+ is_beta:
+ description: 'Is this a beta release?'
+ required: false
+ type: boolean
+ default: false
+ is_alpha:
+ description: 'Is this an alpha release?'
+ required: false
+ type: boolean
+ default: false
+ branch:
+ description: 'Branch to release from'
+ required: true
+ type: string
+ default: 'main'
+
+env:
+ REGISTRY: ghcr.io
+
+jobs:
+ release:
+ runs-on: ubuntu-latest
+ permissions:
+ contents: write
+ packages: write
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v4
+ with:
+ fetch-depth: 0
+ ref: ${{ inputs.branch }}
+
+ - name: Set image base (lowercase for ghcr.io)
+ run: echo "IMAGE_BASE=ghcr.io/$(echo ${{ github.repository_owner }} | tr '[:upper:]' '[:lower:]')/skye" >> $GITHUB_ENV
+
+ - name: Set up Docker Buildx
+ uses: docker/setup-buildx-action@v3
+
+ - name: Log in to Container Registry
+ uses: docker/login-action@v3
+ with:
+ registry: ${{ env.REGISTRY }}
+ username: ${{ github.actor }}
+ password: ${{ secrets.GITHUB_TOKEN }}
+
+ - name: Extract metadata (skye-admin)
+ id: meta-admin
+ uses: docker/metadata-action@v5
+ with:
+ images: ${{ env.IMAGE_BASE }}-admin
+ tags: |
+ type=raw,value=${{ inputs.version }}
+ type=raw,value=latest,enable=${{ !inputs.is_beta && !inputs.is_alpha }}
+
+ - name: Extract metadata (skye-consumers)
+ id: meta-consumers
+ uses: docker/metadata-action@v5
+ with:
+ images: ${{ env.IMAGE_BASE }}-consumers
+ tags: |
+ type=raw,value=${{ inputs.version }}
+ type=raw,value=latest,enable=${{ !inputs.is_beta && !inputs.is_alpha }}
+
+ - name: Extract metadata (skye-serving)
+ id: meta-serving
+ uses: docker/metadata-action@v5
+ with:
+ images: ${{ env.IMAGE_BASE }}-serving
+ tags: |
+ type=raw,value=${{ inputs.version }}
+ type=raw,value=latest,enable=${{ !inputs.is_beta && !inputs.is_alpha }}
+
+ - name: Build and push skye-admin
+ uses: docker/build-push-action@v5
+ with:
+ context: ./skye
+ file: ./skye/cmd/admin/Dockerfile
+ platforms: linux/amd64,linux/arm64
+ push: true
+ tags: ${{ steps.meta-admin.outputs.tags }}
+ labels: ${{ steps.meta-admin.outputs.labels }}
+ cache-from: type=gha
+ cache-to: type=gha,mode=max
+
+ - name: Build and push skye-consumers
+ uses: docker/build-push-action@v5
+ with:
+ context: ./skye
+ file: ./skye/cmd/consumers/Dockerfile
+ platforms: linux/amd64,linux/arm64
+ push: true
+ tags: ${{ steps.meta-consumers.outputs.tags }}
+ labels: ${{ steps.meta-consumers.outputs.labels }}
+ cache-from: type=gha
+ cache-to: type=gha,mode=max
+
+ - name: Build and push skye-serving
+ uses: docker/build-push-action@v5
+ with:
+ context: ./skye
+ file: ./skye/cmd/serving/Dockerfile
+ platforms: linux/amd64,linux/arm64
+ push: true
+ tags: ${{ steps.meta-serving.outputs.tags }}
+ labels: ${{ steps.meta-serving.outputs.labels }}
+ cache-from: type=gha
+ cache-to: type=gha,mode=max
+
+ - name: Create GitHub Release (Production)
+ if: ${{ !inputs.is_beta && !inputs.is_alpha }}
+ uses: actions/create-release@v1
+ env:
+ GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+ with:
+ tag_name: skye/${{ inputs.version }}
+ release_name: Skye ${{ inputs.version }}
+ body: |
+ ## Skye Release ${{ inputs.version }}
+
+ ### Docker Images
+ - **skye-admin:** `${{ env.IMAGE_BASE }}-admin:${{ inputs.version }}` / `:latest`
+ - **skye-consumers:** `${{ env.IMAGE_BASE }}-consumers:${{ inputs.version }}` / `:latest`
+ - **skye-serving:** `${{ env.IMAGE_BASE }}-serving:${{ inputs.version }}` / `:latest`
+
+ ### Quickstart
+ See [skye/docs/QUICKSTART.md](https://github.com/${{ github.repository }}/blob/${{ inputs.branch }}/skye/docs/QUICKSTART.md) for run instructions.
+
+ ### Changes
+ Please see the commit history for detailed changes.
+ draft: false
+ prerelease: false
+
+ - name: Create GitHub Release (Beta)
+ if: ${{ inputs.is_beta }}
+ uses: actions/create-release@v1
+ env:
+ GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+ with:
+ tag_name: skye/${{ inputs.version }}
+ release_name: Skye ${{ inputs.version }} (Beta)
+ body: |
+ ## Skye Beta Release ${{ inputs.version }}
+
+ ⚠️ **This is a beta release** - Use for testing purposes only.
+
+ ### Docker Images
+ - `${{ env.IMAGE_BASE }}-admin:${{ inputs.version }}`
+ - `${{ env.IMAGE_BASE }}-consumers:${{ inputs.version }}`
+ - `${{ env.IMAGE_BASE }}-serving:${{ inputs.version }}`
+
+ ### Changes
+ Please see the commit history for detailed changes.
+ draft: false
+ prerelease: true
+
+ - name: Create GitHub Release (Alpha)
+ if: ${{ inputs.is_alpha }}
+ uses: actions/create-release@v1
+ env:
+ GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+ with:
+ tag_name: skye/${{ inputs.version }}
+ release_name: Skye ${{ inputs.version }} (Alpha)
+ body: |
+ ## Skye Alpha Release ${{ inputs.version }}
+
+ ⚠️ **This is an alpha release** - Experimental build for development and testing.
+
+ ### Docker Images
+ - `${{ env.IMAGE_BASE }}-admin:${{ inputs.version }}`
+ - `${{ env.IMAGE_BASE }}-consumers:${{ inputs.version }}`
+ - `${{ env.IMAGE_BASE }}-serving:${{ inputs.version }}`
+
+ ### Changes
+ Please see the commit history for detailed changes.
+ draft: false
+ prerelease: true
diff --git a/.github/workflows/skye.yml b/.github/workflows/skye.yml
new file mode 100644
index 00000000..45c31437
--- /dev/null
+++ b/.github/workflows/skye.yml
@@ -0,0 +1,56 @@
+name: Skye CI
+
+on:
+ pull_request:
+ branches: [master, develop]
+ paths: ['skye/**']
+ push:
+ branches: [master, develop]
+ paths: ['skye/**']
+
+jobs:
+ build-skye:
+ runs-on: ubuntu-latest
+ defaults:
+ run:
+ working-directory: ./skye
+ steps:
+ - name: Checkout code
+ uses: actions/checkout@v4
+
+ - name: Set up Go
+ uses: actions/setup-go@v4
+ with:
+ go-version: '1.24'
+ cache: false
+
+ - name: Cache Go modules
+ uses: actions/cache@v3
+ with:
+ path: |
+ ~/.cache/go-build
+ ~/go/pkg/mod
+ key: ${{ runner.os }}-go-skye-${{ hashFiles('skye/go.sum') }}
+ restore-keys: |
+ ${{ runner.os }}-go-skye-
+
+ - name: Download dependencies
+ run: go mod download
+
+ - name: Run tests
+ run: go test -v ./...
+
+ - name: Build binaries
+ run: |
+ go build -o /dev/null ./cmd/admin
+ go build -o /dev/null ./cmd/consumers
+ go build -o /dev/null ./cmd/serving
+
+ - name: Run go vet
+ run: go vet ./...
+
+ - name: Install staticcheck
+ run: go install honnef.co/go/tools/cmd/staticcheck@latest
+
+ - name: Run staticcheck
+ run: staticcheck ./...
diff --git a/.github/workflows/trufflebox-ui.yml b/.github/workflows/trufflebox-ui.yml
index 77442b00..e920678f 100644
--- a/.github/workflows/trufflebox-ui.yml
+++ b/.github/workflows/trufflebox-ui.yml
@@ -2,10 +2,10 @@ name: Trufflebox UI CI
on:
pull_request:
- branches: [master, develop]
+ branches: [main, develop]
paths: ['trufflebox-ui/**']
push:
- branches: [master, develop]
+ branches: [main, develop]
paths: ['trufflebox-ui/**']
jobs:
diff --git a/.gitignore b/.gitignore
index 93b602fd..e130cc1d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,10 +4,14 @@ trufflebox-ui/node_modules/
dist/
.env*
.idea/
+.vscode/
workspace/
.vscode/
.cursor/
__pycache__/
+java-sdk/onfs/feature-store-client/target/
+java-sdk/onfs/feature-store-flink-connector-sdk-flink1x/target/
+java-sdk/onfs/feature-store-core/target/
# Dev toggle script artifacts
.internal-configs/
@@ -19,3 +23,11 @@ flashring/performance_results.csv
flashring/mem.prof
flashring/flashring
flashring/flashringtest
+
+
+
+horizon/pem/*.pem
+horizon/pem/*.key
+horizon/configs/*.pem
+go.work
+go.work.sum
diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index c721100c..57dfa835 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -4,6 +4,15 @@ repos:
- id: trufflehog
name: TruffleHog
description: Detect secrets in your data.
- entry: "trufflehog/trufflehog-hook.sh"
+ entry: "pre-commit-scripts/runner.sh"
language: script
stages: ["pre-commit", "pre-push"]
+ - repo: local
+ hooks:
+ - id: post-commit
+ name: Post Commit
+ description: Run post-commit scripts.
+ entry: "post-commit-scripts/runner.sh"
+ language: script
+ stages: ["post-commit"]
+ always_run: true
diff --git a/.vscode/launch.json b/.vscode/launch.json
deleted file mode 100644
index 2decad3c..00000000
--- a/.vscode/launch.json
+++ /dev/null
@@ -1,34 +0,0 @@
-{
- // Use IntelliSense to learn about possible attributes.
- // Hover to view descriptions of existing attributes.
- // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
- "version": "0.2.0",
- "configurations": [
-
- {
- "name": "Shard",
- "type": "go",
- "request": "launch",
- "mode": "debug",
- "program": "${workspaceFolder}/ssd-cache/cmd/shardtest/main.go"
- },
- {
- "name": "Cache",
- "type": "go",
- "request": "launch",
- "mode": "debug",
- "program": "${workspaceFolder}/ssd-cache/cmd/cachetest/main.go"
- },
- {
- "name": "Flashring",
- "type": "go",
- "request": "launch",
- "mode": "debug",
- "program": "${workspaceFolder}/flashring/cmd/flashringtest",
- "env": {
- "PLAN": "readthrough-batched"
- }
- }
-
- ]
-}
\ No newline at end of file
diff --git a/README.md b/README.md
index 508c6f8d..b0c0ff31 100644
--- a/README.md
+++ b/README.md
@@ -1,7 +1,9 @@
-# BharatMLStack
-
-
+
+
+
+
+
@@ -20,121 +22,95 @@
## What is BharatMLStack?
-BharatMLStack is a comprehensive, production-ready machine learning infrastructure platform designed to democratize ML capabilities across India and beyond. Our mission is to provide a robust, scalable, and accessible ML stack that empowers organizations to build, deploy, and manage machine learning solutions at massive scale.
+BharatMLStack is a production-ready, cloud-agnostic ML infrastructure platform that powers real-time feature serving, model inference, and embedding search at massive scale. Built and battle-tested at [Meesho](https://meesho.com), it is designed to help organizations ship ML to production faster, cheaper, and more reliably.
## Our Vision
-- 🎯 **Democratize Machine Learning**: Make advanced ML infrastructure accessible to organizations of all sizes
-- 🚀 **Scale Without Limits**: Built to handle millions of requests per second with enterprise-grade reliability
-- 🇮🇳 **Bharat-First Approach**: Optimized for Indian market needs while maintaining global standards
-- ⚡ **Real-Time Intelligence**: Enable instant decision-making with sub-millisecond feature serving
-- 🔧 **Developer-Friendly**: Intuitive APIs and interfaces that accelerate ML development cycles
+BharatMLStack is built around **four core tenets**:
-## Star History
+### Workflow Integration & Productivity
+> Ship ML to production faster than ever.
-[](https://www.star-history.com/#Meesho/BharatMLStack&Date)
+- **3x faster** experiment-to-deployment cycles
+- **95% reduction** in model onboarding time
-## Running at Million Scale
+### Cloud-Agnostic & Lock-In Free
+> Run anywhere. Own your stack.
-BharatMLStack is battle-tested in production environments, powering:
-- **1M+ feature vector retrievals per second** across distributed deployments
-- **Sub-10ms latency** for real-time feature retrieval
-- **99.99% uptime** with auto-scaling and fault tolerance
-- **Petabyte-scale** feature storage and processing
-- **Multi-region deployments** with global load balancing
+- Runs across **public cloud, on-prem, and edge**
+- Kubernetes-native with zero vendor lock-in
-## Document
-- [Doc](https://meesho.github.io/BharatMLStack/)
-- [Blogs](https://meesho.github.io/BharatMLStack/blog)
-## Core Components
+### Economic Efficiency
+> Do more with less.
-### 📋 Current Releases
-
-| Component | Version | Description |
-|-----------|---------|-------------|
-| 🚀 **Horizon** | `v1.0.0` | Control Plane & Backend |
-| 🎨 **Trufflebox UI** | `v1.0.0` | ML Management Console |
-| 🗄️ **Online Feature Store** | `v1.0.0` | Real-Time Features |
-| 🐹 **Go SDK** | `v1.0.0` | Go Client Library |
-| 🐍 **Python SDK** | `v1.0.1` | Python Client Library |
-| 🚀 **Numerix** | `v1.0.0` | Mathematical Compute Engine |
-
-### 🚀 Horizon - Control Plane & Backend
-The central control plane for BharatMLStack components, serving as the backend for Trufflebox UI.
-- **Component orchestration**: Manages and coordinates all BharatMLStack services
-- **API gateway**: Unified interface for all MLOps and workflows
-
-### 🎨 Trufflebox UI - ML Management Console
-Modern web interface for managing ML models, features, and experiments. Currently it supports:
-- **Feature Registry**: Centralized repository for feature definitions and metadata
-- **Feature Cataloging**: Discovery and search capabilities for available features
-- **Online Feature Store Control System**: Management interface for feature store operations
-- **Approval Flows**: Workflow management for feature deployment and changes
-
-### 🗄️ Online Feature Store - Real-Time Features
-High-performance feature store for real-time ML inference and training.
-- **Real-time serving**: Sub-10ms feature retrieval at scale
-- **Streaming ingestion**: Process millions of feature updates per second
-- **Feature Backward Compatible Versioning**: Track and manage feature evolution
-- **Multi-source integration**: Push from stream, batch and real-time sources
-
-### 🗄️ Numerix - Mathematical Compute Engine
-High-performance feature store for real-time ML inference and training.
-- **Matrix Operations**: High-performance matrix computations and transformations
-- **gRPC API**: Fast binary protocol for efficient data transfer
-- **Multi-format Support**: String and byte-based matrix formats
-- **Optimized Performance**: Built with Rust for maximum efficiency
-- **Scalable Architecture**: Designed for distributed processing
-
-## Key Differentiators
-
-- ✨ **Production-Ready**: Battle-tested components used in high-traffic production systems
-- 🌐 **Cloud Agnostic**: Kubernetes-native, so deploy on the cloud you love
-- 📊 **Observability**: Built-in monitoring, logging
+- **60–70% lower** infrastructure costs vs hyperscaler managed services
+- Optimized resource utilization across CPU and GPU workloads
-## Quick Start
+### Availability & Scalability
+> Enterprise-grade reliability at internet scale.
-🚀 **Get started with BharatMLStack in minutes!**
+- **99.99% uptime** across clusters
+- **1M+ QPS** with low latency
-For comprehensive setup instructions, examples, and deployment guides, see our detailed Quick Start documentation:
+## Designed Truly for Bharat Scale
-📖 **[Quick Start Guide →](./quick-start/README.md)**
+Built for the demands of one of the world's largest e-commerce platforms:
-### What You'll Find:
+| Metric | Performance |
+|--------|-------------|
+| **Feature Store** | 2.4M QPS (batch of 100 id lookups) |
+| **Model Inference** | 1M+ QPS |
+| **Embedding Search** | 500K QPS |
+| **Feature Retrieval Latency** | Sub-10ms |
-- **🐳 Docker Setup**: Complete stack deployment with Docker Compose
-- **📊 Sample Data**: Pre-configured examples to get you started
-- **🔍 Health Checks**: Verify your deployment is working
-- **📝 Step-by-Step Tutorials**: From installation to first feature operations
+## Core Components
-### TL;DR - One Command Setup:
+| Component | Description | Version | Docs |
+|-----------|-------------|---------|------|
+| **[TruffleBox UI](./trufflebox-ui/)** | Web console for feature registry, cataloging, and approval workflows | `v1.3.0` | [Docs](https://meesho.github.io/BharatMLStack/trufflebox-ui/v1.0.0/userguide) |
+| **[Online Feature Store](./online-feature-store/)** | Sub-10ms feature retrieval at millions of QPS with streaming ingestion | `v1.2.0` | [Docs](https://meesho.github.io/BharatMLStack/category/online-feature-store) |
+| **[Inferflow](./inferflow/)** | DAG-based real-time inference orchestration for composable ML pipelines | `v1.0.0` | [Docs](https://meesho.github.io/BharatMLStack/category/inferflow) |
+| **[Numerix](./numerix/)** | Rust-powered math compute engine for high-performance matrix ops | `v1.0.0` | [Docs](https://meesho.github.io/BharatMLStack/category/numerix) |
+| **[Skye](./skye/)** | Vector similarity search with pluggable backends | `v1.0.0` | [Docs](https://meesho.github.io/BharatMLStack/category/skye) |
+| **[Go SDK](./go-sdk/)** | Go client for Feature Store, Interaction Store, and logging | `v1.3.0` | [Docs](https://meesho.github.io/BharatMLStack/category/go-sdk) |
+| **[Python SDK](./py-sdk/)** | Python client libraries for Feature Store and inference logging | `v1.0.1` | [Docs](https://meesho.github.io/BharatMLStack/category/python-sdk) |
+| **[Interaction Store](./interaction-store/)** | ScyllaDB-backed store for user interaction signals at sub-10ms | — | — |
+| **[Horizon](./horizon/)** | Control plane that orchestrates all services and powers TruffleBox UI | `v1.3.0` | — |
+
+> Full documentation at [meesho.github.io/BharatMLStack](https://meesho.github.io/BharatMLStack/) | [Blogs](https://meesho.github.io/BharatMLStack/blog)
+- [All Blog Posts](https://meesho.github.io/BharatMLStack/blog)
+
+## Quick Start
```bash
-# Clone and start the complete stack
git clone https://github.com/Meesho/BharatMLStack.git
cd BharatMLStack/quick-start
-ONFS_VERSION= HORIZON_VERSION= TRUFFLEBOX_VERSION= NUMERIX_VERSION= ./start.sh
+#Set versions
+ONFS_VERSION=v1.2.0 HORIZON_VERSION=v1.3.0 TRUFFLEBOX_VERSION=v1.3.0 NUMERIX_VERSION=v1.0.0
+
+./start.sh
```
-Then follow the [Quick Start Guide](./quick-start/README.md) for detailed setup and usage instructions.
+For step-by-step setup, Docker Compose details, sample data, and health checks, see the full **[Quick Start Guide →](./quick-start/README.md)**.
## Architecture
-BharatMLStack follows a microservices architecture designed for scalability and maintainability. Several components are to be open-sourced
-
-
+
-### 🚀 Quick Navigation
+## Use-Cases
+
+BharatMLStack powers a wide range of ML-driven applications:
-| Component | Documentation | Quick Start |
-|-----------|--------------|-------------|
-| **Online Feature Store** | [Docs](https://meesho.github.io/BharatMLStack/category/online-feature-store) | [Setup](./quick-start/README.md) |
-| **Go SDK** | [Docs](./go-sdk/README.md) | [Examples](./go-sdk/README.md) |
-| **Python SDK** | [Docs](./py-sdk/README.md) | [Quickstart](./py-sdk/README.md) |
-| **User Guide** | [Docs](https://meesho.github.io/BharatMLStack/trufflebox-ui/v1.0.0/userguide) | [Setup](./quick-start/README.md) |
-| **Numerix** | [Docs](https://meesho.github.io/BharatMLStack/category/numerix) | [Setup](./quick-start/README.md) |
+| Use-Case | What BharatMLStack Enables |
+|----------|---------------------------|
+| **Personalized Candidate Generation** | Retrieve and rank millions of candidates in real time using feature vectors and embedding similarity |
+| **Personalized Ranking** | Serve user, item, and context features at ultra-low latency to power real-time ranking models |
+| **Fraud & Risk Detection** | Stream interaction signals and features to detect anomalies and fraudulent patterns in milliseconds |
+| **Image Search** | Run embedding search at 500K QPS to match visual queries against massive product catalogs |
+| **LLM Recommender Systems** | Orchestrate LLM inference pipelines with feature enrichment for next-gen recommendation engines |
+| **DL & LLM Deployments at Scale** | Deploy and scale deep learning and large language models across GPU clusters with Inferflow orchestration |
## Contributing
@@ -142,9 +118,9 @@ We welcome contributions from the community! Please see our [Contributing Guide]
## Community & Support
-- 💬 **Discord**: Join our [community chat](https://discord.gg/XkT7XsV2AU)
-- 🐛 **Issues**: Report bugs and request features on [GitHub Issues](https://github.com/Meesho/BharatMLStack/issues)
-- 📧 **Email**: Contact us at [ml-oss@meesho.com](mailto:ml-oss@meesho.com )
+- **Discord**: Join our [community chat](https://discord.gg/XkT7XsV2AU)
+- **Issues**: Report bugs and request features on [GitHub Issues](https://github.com/Meesho/BharatMLStack/issues)
+- **Email**: Contact us at [ml-oss@meesho.com](mailto:ml-oss@meesho.com)
## License
diff --git a/assets/bharatmlstack-architecture.png b/assets/bharatmlstack-architecture.png
new file mode 100644
index 00000000..afa5b787
Binary files /dev/null and b/assets/bharatmlstack-architecture.png differ
diff --git a/assets/bharatmlstack-logo.png b/assets/bharatmlstack-logo.png
new file mode 100644
index 00000000..9756a1ec
Binary files /dev/null and b/assets/bharatmlstack-logo.png differ
diff --git a/cli-tools/go.mod b/cli-tools/go.mod
index 860ddb30..7205fdd5 100644
--- a/cli-tools/go.mod
+++ b/cli-tools/go.mod
@@ -30,4 +30,4 @@ require (
gopkg.in/inf.v0 v0.9.1 // indirect
gorm.io/driver/mysql v1.5.6 // indirect
gorm.io/gorm v1.25.10 // indirect
-)
+)
\ No newline at end of file
diff --git a/cli-tools/go.sum b/cli-tools/go.sum
index 5b793032..20b99726 100644
--- a/cli-tools/go.sum
+++ b/cli-tools/go.sum
@@ -99,4 +99,4 @@ gorm.io/driver/mysql v1.5.6/go.mod h1:sEtPWMiqiN1N1cMXoXmBbd8C6/l+TESwriotuRRpkD
gorm.io/gorm v1.25.7 h1:VsD6acwRjz2zFxGO50gPO6AkNs7KKnvfzUjHQhZDz/A=
gorm.io/gorm v1.25.7/go.mod h1:hbnx/Oo0ChWMn1BIhpy1oYozzpM15i4YPuHDmfYtwg8=
gorm.io/gorm v1.25.10 h1:dQpO+33KalOA+aFYGlK+EfxcI5MbO7EP2yYygwh9h+s=
-gorm.io/gorm v1.25.10/go.mod h1:hbnx/Oo0ChWMn1BIhpy1oYozzpM15i4YPuHDmfYtwg8=
+gorm.io/gorm v1.25.10/go.mod h1:hbnx/Oo0ChWMn1BIhpy1oYozzpM15i4YPuHDmfYtwg8=
\ No newline at end of file
diff --git a/core/activity-contracts/activity/activity.go b/core/activity-contracts/activity/activity.go
new file mode 100644
index 00000000..5d26857e
--- /dev/null
+++ b/core/activity-contracts/activity/activity.go
@@ -0,0 +1,35 @@
+package activity
+
+import "context"
+
+// GlobalActivityOutputs maps each action name to a list of its result maps.
+// {"noop.log": [{"logged": "hello"}, {"logged": "world"}], "noop.echo": [...]}
+type GlobalActivityOutputs map[string][]map[string]interface{}
+
+// ActivityInput is the generic input passed to all activities.
+type ActivityInput struct {
+ Action string `json:"action"`
+ Params map[string]interface{} `json:"params"`
+ StepName string `json:"step_name"`
+ WorkflowExecutionId string `json:"workflow_execution_id"`
+ Async bool `json:"async"`
+ PluginVersion string `json:"plugin_version"`
+ StepId string `json:"step_id,omitempty"`
+ // Attempt is the 1-based Temporal activity attempt number for this invocation.
+ // Async plugins must include this in the payload they send to the external system
+ // so that callbacks can be routed back to the exact attempt that triggered the work.
+ Attempt int `json:"attempt,omitempty"`
+ // Config holds plugin-specific configuration injected from etcd at call time.
+ // Plugins should read environment-specific values from here instead of os.Getenv,
+ // so that config can be updated in etcd without redeploying the orchestrator.
+ Config map[string]string `json:"config,omitempty"`
+}
+
+// ActivityOutput is the generic output returned by all activities.
+type ActivityOutput struct {
+ Result map[string]interface{} `json:"result,omitempty"`
+ Error string `json:"error,omitempty"`
+}
+
+// ActivityFunc is the function signature that every registered activity must implement.
+type ActivityFunc func(ctx context.Context, globalOutputs GlobalActivityOutputs, input ActivityInput) (ActivityOutput, error)
diff --git a/core/activity-contracts/go.mod b/core/activity-contracts/go.mod
new file mode 100644
index 00000000..7ce73862
--- /dev/null
+++ b/core/activity-contracts/go.mod
@@ -0,0 +1,3 @@
+module github.com/Meesho/BharatMLStack/core/activity-contracts
+
+go 1.25.6
diff --git a/dev-toggle-go.sh b/dev-toggle-go.sh
new file mode 100755
index 00000000..2ba9ecf9
--- /dev/null
+++ b/dev-toggle-go.sh
@@ -0,0 +1,842 @@
+#!/bin/bash
+
+set -e
+
+# Get the script directory (parent directory where this script lives)
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+
+# Colors for output
+RED='\033[0;31m'
+GREEN='\033[0;32m'
+YELLOW='\033[1;33m'
+BLUE='\033[0;34m'
+NC='\033[0m' # No Color
+
+get_available_folders() {
+ local folders=()
+ for dir in "$SCRIPT_DIR"/*; do
+ if [ -d "$dir" ] && [ -f "$dir/go.mod" ]; then
+ local folder_name=$(basename "$dir")
+ folders+=("$folder_name")
+ fi
+ done
+ echo "${folders[@]}"
+}
+
+interactive_select_folder() {
+ local available_folders=($(get_available_folders))
+
+ if [ ${#available_folders[@]} -eq 0 ]; then
+ log_error "No folders with go.mod found in $SCRIPT_DIR"
+ exit 1
+ fi
+
+ echo "" >&2
+ echo "==========================================" >&2
+ echo " Step 1: Select Folder(s)" >&2
+ echo "==========================================" >&2
+ echo "" >&2
+ echo "Available folders:" >&2
+ local index=1
+ for folder in "${available_folders[@]}"; do
+ echo " [$index] $folder" >&2
+ ((index++))
+ done
+ echo "" >&2
+ echo "You can select:" >&2
+ echo " • Single folder: Enter a number (e.g., 1)" >&2
+ echo " • Multiple folders: Enter numbers separated by comma or space (e.g., 1,2 or 1 2 3)" >&2
+ echo "" >&2
+
+ while true; do
+ read -p "Select folder(s): " selection
+
+ # Remove any extra spaces
+ selection=$(echo "$selection" | tr -s ' ' | tr ',' ' ')
+
+ # Validate all selections
+ local valid=true
+ local selected_folders=()
+ local IFS=' '
+ for num in $selection; do
+ if [[ "$num" =~ ^[0-9]+$ ]] && [ "$num" -ge 1 ] && [ "$num" -le ${#available_folders[@]} ]; then
+ selected_folders+=("${available_folders[$((num-1))]}")
+ else
+ valid=false
+ break
+ fi
+ done
+
+ if [ "$valid" = true ] && [ ${#selected_folders[@]} -gt 0 ]; then
+ # Remove duplicates
+ local unique_folders=()
+ for folder in "${selected_folders[@]}"; do
+ local is_duplicate=false
+ for unique in "${unique_folders[@]}"; do
+ if [ "$folder" = "$unique" ]; then
+ is_duplicate=true
+ break
+ fi
+ done
+ if [ "$is_duplicate" = false ]; then
+ unique_folders+=("$folder")
+ fi
+ done
+
+ # Output folders separated by space (will be captured as array) to stdout
+ echo "${unique_folders[@]}"
+ return 0
+ else
+ echo "Invalid selection. Please enter number(s) between 1 and ${#available_folders[@]}." >&2
+ echo " Examples: 1 or 1,2 or 1 2 3" >&2
+ fi
+ done
+}
+
+interactive_select_command() {
+ echo "" >&2
+ echo "==========================================" >&2
+ echo " Step 2: Select Command" >&2
+ echo "==========================================" >&2
+ echo "" >&2
+ echo "Available commands:" >&2
+ echo " [1] enable - Enable development mode (clone internal repo, copy files, update go.mod)" >&2
+ echo " [2] disable - Disable development mode (remove copied files and go.mod changes)" >&2
+ echo " [3] status - Show current development mode status" >&2
+ echo " [4] update - Update internal configs (pull latest from internal repo)" >&2
+ echo "" >&2
+
+ while true; do
+ read -p "Select command (1-4): " selection
+ case "$selection" in
+ 1)
+ echo "enable"
+ return 0
+ ;;
+ 2)
+ echo "disable"
+ return 0
+ ;;
+ 3)
+ echo "status"
+ return 0
+ ;;
+ 4)
+ echo "update"
+ return 0
+ ;;
+ *)
+ echo "Invalid selection. Please enter a number between 1 and 4." >&2
+ ;;
+ esac
+ done
+}
+
+select_internal_repo_branch() {
+ local provided_branch="${1:-}"
+ local branch=""
+
+ # 1) explicit arg wins
+ if [ -n "$provided_branch" ]; then
+ branch="$provided_branch"
+ # 2) env var next
+ elif [ -n "${INTERNAL_REPO_BRANCH:-}" ]; then
+ branch="$INTERNAL_REPO_BRANCH"
+ # 3) interactive prompt if we have a TTY
+ elif [ -t 0 ]; then
+ echo "" >&2
+ echo "==========================================" >&2
+ echo " Step 3: Select Internal Configs Branch" >&2
+ echo "==========================================" >&2
+ echo "" >&2
+ echo "Choose the branch to use from internal configs repo:" >&2
+ echo " [1] develop (default)" >&2
+ echo " [2] main" >&2
+ echo " [3] enter a custom branch name (e.g., feature/my-change)" >&2
+ echo "" >&2
+
+ while true; do
+ read -p "Select branch (1-2 or name): " selection
+ selection="$(echo "${selection:-}" | tr '[:upper:]' '[:lower:]' | tr -d '[:space:]')"
+ case "$selection" in
+ ""|1|develop)
+ branch="develop"
+ break
+ ;;
+ 2|main)
+ branch="main"
+ break
+ ;;
+ 3)
+ read -p "Enter branch name: " custom
+ branch="${custom:-}"
+ break
+ ;;
+ *)
+ # Treat anything else as a branch name
+ branch="$selection"
+ break
+ ;;
+ esac
+ done
+ else
+ # 4) non-interactive default
+ branch="develop"
+ fi
+
+ branch="$(echo "${branch:-}" | tr -d '\r' | sed 's/^[[:space:]]*//;s/[[:space:]]*$//')"
+ if [ -z "$branch" ]; then
+ log_error "Internal configs branch cannot be empty"
+ exit 1
+ fi
+
+ # Validate branch name as a proper git branch ref (safe for checkout/clone)
+ if command -v git >/dev/null 2>&1; then
+ if ! git check-ref-format --branch "$branch" >/dev/null 2>&1; then
+ log_error "Invalid internal configs branch name: '$branch'"
+ exit 1
+ fi
+ fi
+
+ echo "$branch"
+ return 0
+}
+
+print_usage() {
+ echo "Usage: $0 [branch]"
+ echo ""
+ echo "Parameters:"
+ echo " 1. folder-name - Name of the folder to operate on"
+ echo ""
+
+ # Detect and show available folders
+ local available_folders=($(get_available_folders))
+ if [ ${#available_folders[@]} -gt 0 ]; then
+ echo " Available folders:"
+ for folder in "${available_folders[@]}"; do
+ echo " • $folder"
+ done
+ else
+ echo " Available folders: (none found with go.mod)"
+ fi
+
+ echo ""
+ echo " 2. command - Action to perform"
+ echo ""
+ echo " Available commands:"
+ echo " • enable - Enable development mode (clone internal repo, copy files, update go.mod)"
+ echo " • disable - Disable development mode (remove copied files and go.mod changes)"
+ echo " • status - Show current development mode status"
+ echo " • update - Update internal configs (pull latest from internal repo)"
+ echo ""
+ echo " 3. branch - (Optional) Internal configs repo branch to use (default: develop)"
+ echo " Examples: develop, main, feature/my-change"
+ echo " You can also set INTERNAL_REPO_BRANCH env var."
+ echo ""
+ echo "Examples:"
+ if [ ${#available_folders[@]} -gt 0 ]; then
+ local first_folder="${available_folders[0]}"
+ echo " $0 $first_folder enable"
+ echo " $0 $first_folder enable develop"
+ echo " $0 $first_folder enable main"
+ if [ ${#available_folders[@]} -gt 1 ]; then
+ local second_folder="${available_folders[1]}"
+ echo " $0 $second_folder status"
+ fi
+ echo " $0 $first_folder disable"
+ echo " $0 $first_folder update"
+ else
+ echo " $0 online-feature-store enable"
+ echo " $0 horizon status"
+ echo " $0 online-feature-store disable"
+ fi
+ echo ""
+ exit 1
+}
+
+log_info() {
+ echo -e "${GREEN}[INFO]${NC} $1"
+}
+
+log_warn() {
+ echo -e "${YELLOW}[WARN]${NC} $1"
+}
+
+log_error() {
+ echo -e "${RED}[ERROR]${NC} $1"
+}
+
+log_debug() {
+ echo -e "${BLUE}[DEBUG]${NC} $1"
+}
+
+# Validate folder name and set up paths
+validate_and_setup() {
+ FOLDER_NAME="${1:-}"
+ COMMAND="${2:-}"
+
+ if [ -z "$FOLDER_NAME" ]; then
+ log_error "Folder name is required"
+ print_usage
+ fi
+
+ if [ -z "$COMMAND" ]; then
+ log_error "Command is required"
+ print_usage
+ fi
+
+ # Set up paths based on folder name
+ TARGET_DIR="$SCRIPT_DIR/$FOLDER_NAME"
+ STATE_FILE="$TARGET_DIR/.dev-toggle-state"
+ GO_MOD_FILE="$TARGET_DIR/go.mod"
+ GO_MOD_APPEND_FILE="$TARGET_DIR/.go.mod.appended"
+
+ INTERNAL_REPO_URL="https://github.com/Meesho/BharatMLStack-internal-configs"
+ INTERNAL_REPO_DIR="$TARGET_DIR/.internal-configs"
+ INTERNAL_FOLDER_DIR="$INTERNAL_REPO_DIR/$FOLDER_NAME"
+
+ # Validate that target directory exists
+ if [ ! -d "$TARGET_DIR" ]; then
+ log_error "Target directory does not exist: $TARGET_DIR"
+ exit 1
+ fi
+
+ # Validate that go.mod exists in target directory
+ if [ ! -f "$GO_MOD_FILE" ]; then
+ log_error "go.mod not found in target directory: $TARGET_DIR"
+ log_error "This script is designed for Go projects with go.mod files"
+ exit 1
+ fi
+
+ log_debug "Target directory: $TARGET_DIR"
+ log_debug "State file: $STATE_FILE"
+ log_debug "Internal repo directory: $INTERNAL_REPO_DIR"
+ log_debug "Internal folder directory: $INTERNAL_FOLDER_DIR"
+}
+
+check_status() {
+ log_info "=========================================="
+ log_info "Development Mode Status for: $FOLDER_NAME"
+ log_info "=========================================="
+
+ if [ -f "$STATE_FILE" ]; then
+ echo ""
+ echo "Status: ENABLED"
+ echo ""
+
+ # Count files
+ local file_count=$(grep -c "^FILE:" "$STATE_FILE" || echo "0")
+ echo "Files copied: $file_count"
+
+ # Show files
+ if [ "$file_count" -gt 0 ]; then
+ echo ""
+ echo "Copied files:"
+ grep "^FILE:" "$STATE_FILE" | sed 's/^FILE:/ ✓ /'
+ fi
+
+ echo ""
+ echo "go.mod modified: $([ -f "$GO_MOD_APPEND_FILE" ] && echo "YES" || echo "NO")"
+
+ # Show replace directives if they exist
+ if [ -f "$GO_MOD_APPEND_FILE" ]; then
+ local replace_count=$(wc -l < "$GO_MOD_APPEND_FILE")
+ echo "Replace directives: $replace_count"
+ fi
+
+ # Show internal repo status
+ if [ -d "$INTERNAL_REPO_DIR/.git" ]; then
+ echo ""
+ echo "Internal repo:"
+ local commit_hash=$(cd "$INTERNAL_REPO_DIR" && git rev-parse --short HEAD 2>/dev/null || echo "unknown")
+ local branch=$(cd "$INTERNAL_REPO_DIR" && git rev-parse --abbrev-ref HEAD 2>/dev/null || echo "unknown")
+ echo " Branch: $branch"
+ echo " Commit: $commit_hash"
+ fi
+
+ echo ""
+ echo "State file: $STATE_FILE"
+ echo ""
+
+ return 0
+ else
+ echo ""
+ echo "Status: DISABLED"
+ echo ""
+ echo "No active development mode configuration found."
+ echo "Run '$0 $FOLDER_NAME enable' to enable development mode."
+ echo ""
+ return 1
+ fi
+}
+
+clone_or_update_internal_repo() {
+ local target_branch="${INTERNAL_REPO_BRANCH:-develop}"
+
+ if [ -d "$INTERNAL_REPO_DIR/.git" ]; then
+ log_info "Internal configs repo already exists, updating..."
+ log_debug "Repository path: $INTERNAL_REPO_DIR"
+ cd "$INTERNAL_REPO_DIR"
+
+ # Fetch latest changes
+ log_info "Fetching latest changes from origin..."
+ git fetch origin
+ log_debug "Fetch completed"
+
+ log_info "Using branch: $target_branch"
+
+ # Ensure the remote branch exists (and fetch it explicitly if needed)
+ if ! git show-ref --verify --quiet "refs/remotes/origin/$target_branch"; then
+ log_info "Remote branch origin/$target_branch not found locally; fetching it..."
+ git fetch origin "$target_branch" || true
+ fi
+ if ! git show-ref --verify --quiet "refs/remotes/origin/$target_branch"; then
+ log_error "Branch not found in internal configs repo: origin/$target_branch"
+ exit 1
+ fi
+
+ # Switch to the requested branch, tracking origin/
+ local current_branch
+ current_branch=$(git rev-parse --abbrev-ref HEAD)
+ log_debug "Current branch: $current_branch"
+ if [ "$current_branch" != "$target_branch" ]; then
+ log_info "Switching from $current_branch to $target_branch"
+ fi
+ git checkout -B "$target_branch" "origin/$target_branch"
+ log_debug "Branch checkout completed"
+
+ # Reset to latest
+ log_info "Resetting to origin/$target_branch..."
+ git reset --hard "origin/$target_branch"
+ local commit_hash=$(git rev-parse --short HEAD)
+ log_info "Updated to commit: $commit_hash"
+
+ cd "$TARGET_DIR"
+ else
+ log_info "Internal configs repo not found, cloning..."
+ log_debug "Cloning from: $INTERNAL_REPO_URL"
+ log_debug "Destination: $INTERNAL_REPO_DIR"
+ log_debug "Branch: $target_branch"
+ rm -rf "$INTERNAL_REPO_DIR"
+ git clone -b "$target_branch" "$INTERNAL_REPO_URL" "$INTERNAL_REPO_DIR"
+ local commit_hash=$(cd "$INTERNAL_REPO_DIR" && git rev-parse --short HEAD)
+ log_info "Clone completed at commit: $commit_hash"
+ fi
+}
+
+enable_dev_mode() {
+ log_info "=========================================="
+ log_info "Starting development mode enablement for: $FOLDER_NAME"
+ log_info "=========================================="
+
+ if [ -f "$STATE_FILE" ]; then
+ log_warn "Development mode is already enabled!"
+ echo "Run '$0 $FOLDER_NAME disable' first to revert, or delete $STATE_FILE if state is corrupted."
+ exit 1
+ fi
+
+ log_debug "State file: $STATE_FILE"
+ log_debug "Working directory: $TARGET_DIR"
+
+ # Clone or update the internal repo
+ log_info "Step 1: Fetching internal configurations..."
+ clone_or_update_internal_repo
+
+ # Check if folder directory exists in internal repo
+ log_info "Step 2: Validating internal repository structure..."
+ log_debug "Looking for: $INTERNAL_FOLDER_DIR"
+ if [ ! -d "$INTERNAL_FOLDER_DIR" ]; then
+ log_error "$FOLDER_NAME directory not found in internal configs repo!"
+ log_error "Expected path: $INTERNAL_FOLDER_DIR"
+ exit 1
+ fi
+ log_debug "✓ $FOLDER_NAME directory found"
+
+ # Initialize state file
+ log_info "Step 3: Initializing state tracking..."
+ echo "# Dev toggle state - DO NOT EDIT MANUALLY" > "$STATE_FILE"
+ echo "# Generated on $(date)" >> "$STATE_FILE"
+ echo "# Folder: $FOLDER_NAME" >> "$STATE_FILE"
+ log_debug "Created state file: $STATE_FILE"
+
+ # Find and copy all .go files and config files from internal repo
+ # Copy: .go sources and common config types (.yaml, .yml, .json, .env, .pbtxt)
+ log_info "Step 4: Searching for .go and config files to copy..."
+ log_debug "Scanning directory: $INTERNAL_FOLDER_DIR"
+
+ local copied_count=0
+ local find_patterns=(-name "*.go" -o -name "*.yaml" -o -name "*.yml" -o -name "*.json" -o -name "*.env" -o -name "*.pbtxt")
+ local file_count
+ file_count=$(find "$INTERNAL_FOLDER_DIR" -type f \( "${find_patterns[@]}" \) | wc -l)
+ log_info "Found $file_count file(s) to copy (.go and configs)"
+
+ while IFS= read -r -d '' src_file; do
+ # Get relative path from INTERNAL_FOLDER_DIR
+ rel_path="${src_file#$INTERNAL_FOLDER_DIR/}"
+ dest_file="$TARGET_DIR/$rel_path"
+ dest_dir="$(dirname "$dest_file")"
+
+ # Create destination directory if it doesn't exist
+ if [ ! -d "$dest_dir" ]; then
+ log_debug "Creating directory: $dest_dir"
+ mkdir -p "$dest_dir"
+ fi
+
+ # Check if file already exists
+ if [ -f "$dest_file" ]; then
+ log_warn "File already exists, will be overwritten: $rel_path"
+ fi
+
+ # Copy the file
+ log_debug "Copying: $src_file -> $dest_file"
+ cp "$src_file" "$dest_file"
+ log_info "✓ Copied: $rel_path"
+
+ # Record in state file
+ echo "FILE:$rel_path" >> "$STATE_FILE"
+ ((copied_count++))
+ done < <(find "$INTERNAL_FOLDER_DIR" -type f \( "${find_patterns[@]}" \) -print0)
+
+ log_info "Successfully copied $copied_count file(s)"
+
+ # Check if there's a go.mod file in internal repo with replace directives
+ log_info "Step 5: Processing go.mod modifications..."
+ if [ -f "$INTERNAL_FOLDER_DIR/go.mod" ]; then
+ log_debug "Found go.mod in internal configs: $INTERNAL_FOLDER_DIR/go.mod"
+
+ # Extract require/replace directives from internal go.mod.
+ # Supports both single-line directives and block forms:
+ # require ( ... )
+ # replace ( ... )
+ # We normalize block entries into single-line statements to keep the appended section simple.
+ local extracted_lines
+ extracted_lines="$(
+ awk '
+ function ltrim(s) { sub(/^[ \t]+/, "", s); return s }
+ BEGIN { in_req=0; in_rep=0 }
+ {
+ line=$0
+
+ if (line ~ /^require[ \t]*\(/) { in_req=1; next }
+ if (line ~ /^replace[ \t]*\(/) { in_rep=1; next }
+
+ if (in_req) {
+ if (line ~ /^\)/) { in_req=0; next }
+ trimmed=ltrim(line)
+ if (trimmed=="" || trimmed ~ /^\/\//) next
+ print "require " trimmed
+ next
+ }
+
+ if (in_rep) {
+ if (line ~ /^\)/) { in_rep=0; next }
+ trimmed=ltrim(line)
+ if (trimmed=="" || trimmed ~ /^\/\//) next
+ print "replace " trimmed
+ next
+ }
+
+ if (line ~ /^require[ \t]+/ && line !~ /^require[ \t]*\(/) { print line; next }
+ if (line ~ /^replace[ \t]+/ && line !~ /^replace[ \t]*\(/) { print line; next }
+ }
+ ' "$INTERNAL_FOLDER_DIR/go.mod" | sed '/^[[:space:]]*$/d'
+ )"
+
+ if [ -n "$extracted_lines" ]; then
+ printf "%s\n" "$extracted_lines" > "$GO_MOD_APPEND_FILE"
+
+ local extracted_count
+ extracted_count=$(wc -l < "$GO_MOD_APPEND_FILE")
+ log_info "Found $extracted_count directive(s) (require/replace) to append"
+ log_debug "Directives to append:"
+ while IFS= read -r line; do
+ log_debug " $line"
+ done < "$GO_MOD_APPEND_FILE"
+
+ # Append to current go.mod
+ log_info "Appending to $GO_MOD_FILE..."
+ echo "" >> "$GO_MOD_FILE"
+ echo "// Added by dev-toggle-go.sh - DO NOT EDIT" >> "$GO_MOD_FILE"
+ cat "$GO_MOD_APPEND_FILE" >> "$GO_MOD_FILE"
+
+ log_info "✓ Successfully appended require/replace directives to go.mod"
+ else
+ log_warn "No require/replace directives found in internal go.mod"
+ rm -f "$GO_MOD_APPEND_FILE"
+ fi
+ else
+ log_warn "No go.mod found in internal configs at: $INTERNAL_FOLDER_DIR/go.mod"
+ fi
+
+ # Run go mod tidy
+ log_info "Step 6: Running go mod tidy..."
+ log_debug "Changing to directory: $TARGET_DIR"
+ cd "$TARGET_DIR"
+ log_debug "Executing: go mod tidy"
+ go mod tidy
+ log_info "✓ go mod tidy completed successfully"
+
+ log_info "=========================================="
+ log_info "✓ Development mode enabled successfully!"
+ log_info "=========================================="
+ echo ""
+ echo "Summary:"
+ echo " Folder: $FOLDER_NAME"
+ echo " Files copied: $copied_count"
+ echo " go.mod updated: $([ -f "$GO_MOD_APPEND_FILE" ] && echo "YES" || echo "NO")"
+ echo " State file: $STATE_FILE"
+ if [ "$FOLDER_NAME" = "horizon" ]; then
+ echo ""
+ echo "To run tests including internal (meesho) config tests, use:"
+ echo " cd $TARGET_DIR && go test -tags=meesho ./..."
+ echo "Without -tags=meesho, only the standard tests run (internal test files are skipped)."
+ fi
+}
+
+disable_dev_mode() {
+ log_info "=========================================="
+ log_info "Starting development mode disablement for: $FOLDER_NAME"
+ log_info "=========================================="
+
+ if [ ! -f "$STATE_FILE" ]; then
+ log_error "Development mode is not enabled or state file is missing!"
+ log_error "Expected state file: $STATE_FILE"
+ echo "Nothing to disable."
+ exit 1
+ fi
+
+ log_debug "State file found: $STATE_FILE"
+ log_debug "Working directory: $TARGET_DIR"
+
+ # Remove copied files
+ log_info "Step 1: Removing copied files..."
+ local file_count=$(grep -c "^FILE:" "$STATE_FILE" || echo "0")
+ log_info "Found $file_count file(s) to remove"
+
+ local removed_count=0
+ while IFS= read -r line; do
+ if [[ "$line" =~ ^FILE:(.+)$ ]]; then
+ rel_path="${BASH_REMATCH[1]}"
+ file="$TARGET_DIR/$rel_path"
+
+ log_debug "Attempting to remove: $file"
+ if [ -f "$file" ]; then
+ rm "$file"
+ log_info "✓ Removed: $rel_path"
+ ((removed_count++))
+ else
+ log_warn "File not found (may have been manually deleted): $rel_path"
+ fi
+ fi
+ done < "$STATE_FILE"
+
+ log_info "Successfully removed $removed_count file(s)"
+
+ # Revert go.mod changes if they were made
+ log_info "Step 2: Reverting go.mod changes..."
+ if [ -f "$GO_MOD_APPEND_FILE" ]; then
+ log_debug "Found append file: $GO_MOD_APPEND_FILE"
+
+ # Find the marker line and remove everything from that line onwards
+ if grep -q "// Added by dev-toggle-go.sh - DO NOT EDIT" "$GO_MOD_FILE"; then
+ log_debug "Found marker comment in go.mod"
+ local lines_before=$(wc -l < "$GO_MOD_FILE")
+
+ # Use sed to delete from the marker line to end of file
+ log_debug "Removing lines from marker to end of file..."
+ sed -i.bak '/\/\/ Added by dev-toggle-go.sh - DO NOT EDIT/,$d' "$GO_MOD_FILE"
+ rm -f "${GO_MOD_FILE}.bak"
+
+ # Remove any trailing empty lines that might be left
+ log_debug "Cleaning up trailing empty lines..."
+ while [ -s "$GO_MOD_FILE" ]; do
+ last_line=$(tail -n 1 "$GO_MOD_FILE")
+ if [ -z "$last_line" ] || [ "$last_line" = $'\n' ]; then
+ # Remove last line if empty
+ sed -i.bak '$ d' "$GO_MOD_FILE" 2>/dev/null || {
+ # Fallback for systems without sed -i
+ head -n -1 "$GO_MOD_FILE" > "${GO_MOD_FILE}.tmp"
+ mv "${GO_MOD_FILE}.tmp" "$GO_MOD_FILE"
+ }
+ rm -f "${GO_MOD_FILE}.bak"
+ else
+ break
+ fi
+ done
+
+ local lines_after=$(wc -l < "$GO_MOD_FILE")
+ local lines_removed=$((lines_before - lines_after))
+ log_info "✓ Removed $lines_removed line(s) from go.mod"
+ else
+ log_warn "Marker comment not found in go.mod (may have been manually edited)"
+ fi
+
+ log_debug "Removing append file: $GO_MOD_APPEND_FILE"
+ rm -f "$GO_MOD_APPEND_FILE"
+ else
+ log_debug "No append file found, skipping go.mod revert"
+ fi
+
+ # Run go mod tidy
+ log_info "Step 3: Running go mod tidy..."
+ log_debug "Changing to directory: $TARGET_DIR"
+ cd "$TARGET_DIR"
+ log_debug "Executing: go mod tidy"
+ go mod tidy
+ log_info "✓ go mod tidy completed successfully"
+
+ # Clean up state file
+ log_info "Step 4: Cleaning up state file..."
+ log_debug "Removing: $STATE_FILE"
+ rm -f "$STATE_FILE"
+ log_info "✓ State file removed"
+
+ # Remove internal configs directory
+ log_info "Step 5: Removing internal configs directory..."
+ if [ -d "$INTERNAL_REPO_DIR" ]; then
+ log_debug "Removing directory: $INTERNAL_REPO_DIR"
+ rm -rf "$INTERNAL_REPO_DIR"
+ log_info "✓ Internal configs directory removed"
+ else
+ log_debug "Internal configs directory not found, skipping"
+ fi
+
+ log_info "=========================================="
+ log_info "✓ Development mode disabled successfully!"
+ log_info "=========================================="
+}
+
+update_internal_configs() {
+ log_info "=========================================="
+ log_info "Updating internal configurations for: $FOLDER_NAME"
+ log_info "=========================================="
+
+ if [ ! -f "$STATE_FILE" ]; then
+ log_error "Development mode is not enabled!"
+ log_error "Expected state file: $STATE_FILE"
+ echo "Run '$0 $FOLDER_NAME enable' first."
+ exit 1
+ fi
+
+ log_info "Current state: Development mode is ENABLED"
+ log_info "Update strategy: Disable -> Re-enable with latest configs"
+ echo ""
+
+ # Disable current dev mode
+ log_info "Phase 1: Disabling current development mode..."
+ disable_dev_mode
+
+ echo ""
+ log_info "Phase 2: Re-enabling development mode with latest configs..."
+ # Re-enable with fresh configs
+ enable_dev_mode
+
+ echo ""
+ log_info "=========================================="
+ log_info "✓ Internal configs updated successfully!"
+ log_info "=========================================="
+}
+
+# Main script logic
+FOLDER_NAME_INPUT="${1:-}"
+COMMAND="${2:-}"
+BRANCH_INPUT="${3:-}"
+
+# Interactive mode: prompt for missing parameters
+if [ -z "$FOLDER_NAME_INPUT" ]; then
+ echo "=========================================="
+ echo " Development Toggle for Go Projects"
+ echo "=========================================="
+ FOLDER_NAME_INPUT=$(interactive_select_folder)
+fi
+
+if [ -z "$COMMAND" ]; then
+ COMMAND=$(interactive_select_command)
+fi
+
+# If command needs internal configs, choose the branch once (applies to all selected folders)
+if [ "$COMMAND" = "enable" ] || [ "$COMMAND" = "update" ]; then
+ INTERNAL_REPO_BRANCH="$(select_internal_repo_branch "$BRANCH_INPUT")"
+ log_debug "Internal configs branch: $INTERNAL_REPO_BRANCH"
+fi
+
+# Parse folder names (support multiple folders)
+FOLDER_NAMES=($FOLDER_NAME_INPUT)
+
+# If only one folder, process it directly
+if [ ${#FOLDER_NAMES[@]} -eq 1 ]; then
+ FOLDER_NAME="${FOLDER_NAMES[0]}"
+
+ # Validate and set up paths
+ validate_and_setup "$FOLDER_NAME" "$COMMAND"
+
+ log_debug "Script started with folder: $FOLDER_NAME, command: $COMMAND"
+ log_debug "Script directory: $SCRIPT_DIR"
+ log_debug "Target directory: $TARGET_DIR"
+ echo ""
+
+ case "$COMMAND" in
+ enable)
+ log_debug "Command: enable"
+ enable_dev_mode
+ ;;
+ disable)
+ log_debug "Command: disable"
+ disable_dev_mode
+ ;;
+ status)
+ log_debug "Command: status"
+ check_status
+ ;;
+ update)
+ log_debug "Command: update"
+ update_internal_configs
+ ;;
+ *)
+ log_error "Invalid command: $COMMAND"
+ print_usage
+ ;;
+ esac
+else
+ # Multiple folders selected - process each one
+ echo ""
+ log_info "Processing ${#FOLDER_NAMES[@]} folder(s) with command: $COMMAND"
+ echo ""
+
+ for FOLDER_NAME in "${FOLDER_NAMES[@]}"; do
+ echo ""
+ log_info "=========================================="
+ log_info "Processing: $FOLDER_NAME"
+ log_info "=========================================="
+ echo ""
+
+ # Validate and set up paths for this folder
+ validate_and_setup "$FOLDER_NAME" "$COMMAND"
+
+ case "$COMMAND" in
+ enable)
+ enable_dev_mode
+ ;;
+ disable)
+ disable_dev_mode
+ ;;
+ status)
+ check_status
+ ;;
+ update)
+ update_internal_configs
+ ;;
+ *)
+ log_error "Invalid command: $COMMAND"
+ print_usage
+ exit 1
+ ;;
+ esac
+ done
+
+ echo ""
+ log_info "=========================================="
+ log_info "✓ Completed processing all ${#FOLDER_NAMES[@]} folder(s)"
+ log_info "=========================================="
+fi
+
diff --git a/docs-src/blog/authors.yml b/docs-src/blog/authors.yml
index 2af81d4d..376741b0 100644
--- a/docs-src/blog/authors.yml
+++ b/docs-src/blog/authors.yml
@@ -5,22 +5,22 @@ adarsha:
image_url: https://github.com/a0d00kc.png
aditya:
name: Aditya Kumar
- title: SDE-III @ Meesho
+ title: Lead Software Engineer @ Meesho
url: https://github.com/Adit2607
image_url: https://github.com/Adit2607.png
jigar:
name: Jigar Dave
- title: SDE-IV @ Meesho
+ title: Lead Software Engineer @ Meesho
url: https://github.com/jigarpatel26
image_url: https://github.com/jigarpatel26.png
jaya:
name: Jaya Kumar
- title: MLE-III @ Meesho
+ title: Lead ML Engineer @ Meesho
url: https://github.com/jayakommuru
image_url: https://github.com/jayakommuru.png
bhawani:
name: Bhawani Singh
- title: SDE-IV @ Meesho
+ title: Architect @ Meesho
url: https://github.com/singh-bhawani
image_url: https://github.com/singh-bhawani.png
mohit:
diff --git a/docs-src/blog/bharatmlstack-history/post-one/bharatmlstack.png b/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-from-chaos-to-cutting-edge/bharatmlstack.png
similarity index 100%
rename from docs-src/blog/bharatmlstack-history/post-one/bharatmlstack.png
rename to docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-from-chaos-to-cutting-edge/bharatmlstack.png
diff --git a/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-from-chaos-to-cutting-edge/bms.png b/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-from-chaos-to-cutting-edge/bms.png
new file mode 100644
index 00000000..b397fc88
Binary files /dev/null and b/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-from-chaos-to-cutting-edge/bms.png differ
diff --git a/docs-src/blog/bharatmlstack-history/post-one/first-gen-arch.png b/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-from-chaos-to-cutting-edge/first-gen-arch.png
similarity index 100%
rename from docs-src/blog/bharatmlstack-history/post-one/first-gen-arch.png
rename to docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-from-chaos-to-cutting-edge/first-gen-arch.png
diff --git a/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-from-chaos-to-cutting-edge/index.md b/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-from-chaos-to-cutting-edge/index.md
new file mode 100644
index 00000000..fd6dc4b9
--- /dev/null
+++ b/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-from-chaos-to-cutting-edge/index.md
@@ -0,0 +1,238 @@
+---
+title: "Building Meesho’s ML Platform: From Chaos to Cutting-Edge (Part 1)"
+description: "How Meesho transitioned from batch-based recommendations to a real-time ML platform—building an Online Feature Store, Interaction Store, and DAG execution framework that became BharatMLStack."
+slug: building-meeshos-mlplatform
+authors: [adarsha, aditya, bhawani, jigar]
+date: 2022-11-15
+tags: [online-feature-store, interaction-store, mlplatform, meesho]
+---
+
+It all started in early 2022, over a casual Friday evening catch-up. Like many great origin stories, this one began with friendly banter between a group of backend engineers and data scientists. As the conversations unfolded, so did the roasting—until one remark hit a little too close to home:
+
+*"Why are we still crunching data for Monthly Active Users (MAU) when the next day it’s all about Daily Active Users (DAU)?"*
+
+The laughter died down, and the question lingered. When we regrouped on Monday—clear-headed and slightly reflective—we decided to dig into the numbers. What they discovered was quite revealing: a large portion of compute resources wasn’t being put to good use.
+Much of the system’s effort was spent supporting users who weren’t actively engaging, and even for new users, the experience wasn’t optimized to make a meaningful impact.
+
+At the same time, Meesho had just launched a company-wide initiative to reduce costs—and every team had to contribute. This realization sparked the journey that would eventually lead to the **Meesho ML Platform**, known today as **BharatMLStack**.
+
+
+
+Before the ML Platform, our recommendation and ranking pipelines followed a batch processing approach:
+- **Data Ingestion**: The Data Platform team executed ETL jobs to ingest raw user data—including user profiles, interaction logs, and product impressions—into designated S3 buckets.
+- **Layer 1**: Embedding Generation: On the Data Science side, Spark jobs pulled data from multiple S3 sources, cleaned and preprocessed it, and applied matrix factorization to generate user and item embeddings. The processed data and embeddings were then stored back in S3 in a structured format.
+- **Layer 2**: Candidate Generation (CG): In this stage, Spark jobs leveraged embeddings and historical interaction data to generate candidate recommendations for users. These candidate lists were subsequently written to S3.
+- **Layer 3**: Ranking and Merging – A final round of processing ranked the generated candidates using ML models, combined different candidate lists, and stored the final ranked recommendations in a caching system.
+- **Serving**: A microservice retrieved ranked recommendations from an in-memory data store via exposed APIs, delivering personalized listings across key surfaces such as "For You" and Category Landing Pages (CLP).
+
+This approach held up well—until Meesho started seeing a significant surge in traffic.
+
+## The Turning Point: From Batch to Real-Time
+
+At this time, the team was iterating on new **Ranker models**, and real-time inference seemed like the next logical step. But Rankers needed **real-time feature retrieval**, which meant an **online feature store** had to be built first.
+
+Exploring open-source options led to **cost vs. performance trade-offs**, but Meesho’s surging traffic meant that **latency and stability were non-negotiable**. After multiple debates and stakeholder discussions, a bold decision was made:
+
+*We would build our own feature store.*
+
+Meanwhile, efforts began to bring **Candidate Generators (CGs)** to real-time. The challenge? **Storing and retrieving user interactions quickly enough** to power real-time recommendations.
+
+As the team dove deeper, a new roadblock emerged:
+Our ML jobs were orchestrated using **Airflow DAGs**, giving data scientists flexibility in experimentation. But transitioning to real-time execution threatened this agility. Every change would now require backend engineering support, **slowing down iteration cycles**.
+
+That’s when the idea struck:
+We needed a **framework for real-time DAG execution**—one that preserved the same flexibility as Airflow but worked for **streaming data**.
+
+This moment shaped the **next phase of our journey**.
+
+## First Generation Design
+
+
+
+# Laying the Groundwork: The First-Gen ML Platform
+
+To solve these challenges, the team built three foundational components:
+
+
+### 1. IOP Framework: A Real-Time DAG Executor
+
+- **Reusable Nodes**: Each DAG node (e.g., an invocation to a CG service, a ranker, or a filter) had to be implemented only once. After that, it could be reused across any workflow by referencing it in config.
+- **Config-driven Dynamic Graphs**: Execution graphs were defined as adjacency lists stored in **ZooKeeper**, allowing teams to modify the sequence or structure of operations without touching application code.
+- **Plug-and-play CGs**: The Candidate Generator interface was preserved, so a single CG node could call any CG service by passing `cg_name` in the request. This drastically reduced the code surface area and improved maintainability.
+- **Production-Grade DAGs**: DAGs were designed to execute in **low-latency real-time environments**, with support for **parallel execution, retries, and branching**.
+
+[More about IOP DAG](https://www.meesho.io/blog/rebuilding-meeshos-ranking-platform)
+
+
+### 2. Online Feature Store - 0th Version
+
+- Used **Cassandra** and **Redis** for low-latency feature serving.
+- Maintained feature consistency using **Feature Groups** with TTL-based expiry.
+- A hybrid schema was used: feature keys stored in **ZooKeeper**, data stored in **compact arrays**.
+
+
+### 3. Interaction Store - 0th Version
+
+- Captured real-time user interactions like clicks, orders, and add-to-cart events.
+- Stored event data in **Redis ZSETs (sorted sets)** to enable fast lookups for recommendation engines.
+- Provided an API to fetch a user's **last _k_ interactions** or **interactions within a time window**.
+
+
+With these components in place, **real-time ML at Meesho became a reality**.
+
+This was just the beginning.
+
+## Building the Online Feature Store - 0th Version
+
+
+
+### Choosing the Right Tech Stack
+
+We spent considerable time evaluating various databases, caches, and communication protocols for our **online feature store**. After carefully weighing **cost, latency, throughput**, and **operational stability**, we settled on a combination of:
+
+- **Cassandra** and **Redis** for storage
+- **gRPC + Proto3** as our communication layer
+
+
+### Streamlining the Data Flow
+
+To keep things simple in the initial version:
+
+- **Feature engineering jobs** wrote raw outputs to an **S3 bucket**
+- A **daily feature push job**:
+ - Read from S3
+ - Grouped related features into **Feature Groups** (ensuring consistency)
+ - Pushed them to **Kafka**
+
+For features requiring frequent updates:
+
+- **Ad-hoc jobs** computed features in higher frequency
+- These jobs pushed to both **Kafka** and **S3** (S3 preserved historical data for future model training)
+
+
+## The Challenges: Data Format and Storage
+
+One of the most critical design challenges was how to store feature data **efficiently and consistently**, especially in databases like **Cassandra** and **Redis**, which come with unique storage constraints.
+
+We had to solve for three key requirements:
+
+- ### Feature Consistency
+ When a feature group contains features like `order_count_1h` and `click_count_1h`, both must reflect the **same time window**. Inconsistent updates would lead to **unreliable model predictions**.
+
+- ### TTL Granularity
+ Each feature group required an **expiry timestamp**, so that **all features within it expired together**—preserving consistency during reads.
+
+- ### Extensibility Across Databases
+ We anticipated that infra needs would evolve. To future-proof our system, the data format was designed to be **decoupled from DB-specific layouts**, enabling portability to systems like **ScyllaDB**, **DynamoDB**, **HBase**, or **BigTable**.
+
+
+---
+
+## Overcoming Technical Constraints
+At the time, we were using Cassandra, which not only imposed a soft limit of 75 columns per row, but also exhibited significant performance degradation as the number of columns increased further, particularly in memory constrained machines. Wide rows caused high memory usage during reads, unpredictable latencies due to heavy deserialization overhead, and inefficiencies during compactions and repairs. This ruled out the naive "one column per feature" approach. We needed a format that was compact, minimized the number of columns, and remained efficient and portable across different storage systems.
+
+## The Solution: Schema Separation
+
+We introduced the concept of Feature Groups—logical groupings of features that must remain consistent with one another.
+To represent these groups efficiently, we adopted a layered storage approach:
+
+- **Feature Labels (Keys)** were stored in ZooKeeper, serving as the schema.
+- **Feature Values** were stored as a comma-separated string array in Cassandra or Redis.
+- **Expiry Timestamp and Schema Version** were appended using a semi-colon delimiter at the end of the string.
+
+Example:
+
+```bash
+feature_1_value,feature_2_value,feature_3_value;expiry_ts
+```
+
+This format allowed:
+- Consistent writes and reads at the group level
+- Easy parsing of feature values using the schema lookup from ZooKeeper
+- Efficient storage with minimal DB column usage
+- Support for per-group TTLs and schema evolution
+
+## Tracking Changes in Feature Groups
+Feature groups don’t stay static. As models evolve, features get added, renamed, or removed. But schema changes often go live before the data is ready—and stopping ingestion just to wait for everything to align isn't feasible.
+
+### Common Real-World Scenarios:
+- A new feature is added to the schema, but ingestion jobs still use the older schema version.
+- Ongoing writes don’t include the newly added feature, and stopping ingestion would break freshness for existing features.
+- During serving, models request a mix of old and new features, depending on rollout stages.
+
+## The Solution: Schema Versioning
+We solved this with versioned feature group schemas, which unlocked several capabilities:
+- ### Backward Compatibility
+ Older ingestion jobs can continue writing using older schema versions. During reads, the system uses the schema version embedded in the value to interpret the data correctly.
+- ### Partial Availability Handling
+ During inference, if some features in the request aren’t available (due to rollout delays or missing data), the system serves default values, ensuring the inference call doesn’t fail.
+- ### Safe Writes Without Pipeline Pauses
+ With schema versioning, we no longer had to stop ingestion pipelines for schema updates. Writes using previous versions can continue safely, and downstream consumers evolve independently.
+This design gave us the flexibility to move fast without breaking things—preserving data quality, enabling experimentation, and ensuring reliability at scale.
+
+
+
+## Interaction Store - 0th Version
+
+
+
+To power real-time Candidate Generators (CGs), we needed fast access to user behavior signals—like what a user recently clicked, ordered, or added to their cart. These interactions form the basis for many real-time recommendations, such as **Similar Products**, **People Also Viewed**, or **Recently Ordered Again**.
+For the **0th version** of the Interaction Store, we focused on a design that was **simple, fast, and reliable** — optimized for high-throughput ingestion and low-latency lookups.
+
+## Event Ingestion
+We instrumented our backend services to emit key user interaction events to Kafka in real time. These included:
+- Click
+- Order
+- Add to Cart
+- Wishlist
+- Share
+
+Each event carried essential metadata:
+- userId — uniquely identifies the user
+- productId — the item being interacted with
+- timestamp — the moment the interaction occurred
+
+This decoupled the interaction logging from storage, allowing ingestion and consumption to scale independently.
+
+## Storage Design
+To store these events, we built Kafka consumers that processed the incoming streams and wrote the data into Redis, using sorted sets (ZSETs) as the primary data structure.
+
+### Why Redis?
+Redis gave us:
+- **Low-latency** reads and writes
+- **Time-ordered data** using ZSETs (via score = timestamp)
+- **Native TTL support**, if needed in later versions
+- **In-memory performance** —ideal for real-time CGs
+
+### Storage Structure
+Each user’s interactions were stored using a composite key format, uniquely identifying the user and interaction type. This structure allowed efficient organization and quick retrieval of recent activity for recommendation generation:
+
+```bash
+userId_eventType → ZSET[...(pid, ts)...]
+```
+
+Within each ZSET:
+
+- The **timestamp** served as the score, maintaining temporal order
+- The **productId** (optionally with metadata) was the **value**
+
+This allowed us to efficiently retrieve the interactions with HTTP-based API server with two query modes:
+- Fetch the **last k interactions** of a specific type for a given user with `ZREVRANGE(userId_eventType, count)`
+- Retrieve **all interactions within a time range** (e.g., last 24 hours) with `ZREVRANGEBYSCORE(userId_eventType, timeRange)`
+
+### Built-in Guardrails
+Since Redis was the sole store, we implemented High Availability (HA) to prevent data loss. To optimize memory usage, we also enforced size limits per event type—only storing the last k interactions per user, with older entries getting truncated.
+
+## Conclusion: Laying the Foundation for Real-Time ML
+
+In this first phase, we tackled the **fundamentals**—shifting from batch-based recommendations to a **real-time Recommendation** using ML platform that could keep up with Meesho’s growth.
+
+With the **IOP Framework**, **Online Feature Store**, and **Interaction Store**, we built the core infrastructure to support real-time personalization at scale. These wins have already unlocked:
+- ✅ Faster, more dynamic recommendations for millions of users.
+- ✅ Better infrastructure efficiency, reducing wasted compute power.
+- ✅ A flexible, modular system that allows for further experimentation.
+
+But this is just the beginning. While we've solved key challenges, **certain roadblocks remain** —from optimizing **cost-performance trade-offs** to **seamlessly evolving schemas**.
+
+
+This foundational work laid the path for a reliable and scalable **real-time feature serving layer**.
\ No newline at end of file
diff --git a/docs-src/blog/bharatmlstack-history/post-one/interaction-store-v0.png b/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-from-chaos-to-cutting-edge/interaction-store-v0.png
similarity index 100%
rename from docs-src/blog/bharatmlstack-history/post-one/interaction-store-v0.png
rename to docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-from-chaos-to-cutting-edge/interaction-store-v0.png
diff --git a/docs-src/blog/bharatmlstack-history/post-one/logo.jpg b/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-from-chaos-to-cutting-edge/logo.jpg
similarity index 100%
rename from docs-src/blog/bharatmlstack-history/post-one/logo.jpg
rename to docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-from-chaos-to-cutting-edge/logo.jpg
diff --git a/docs-src/blog/bharatmlstack-history/post-one/old-batch-arch.png b/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-from-chaos-to-cutting-edge/old-batch-arch.png
similarity index 100%
rename from docs-src/blog/bharatmlstack-history/post-one/old-batch-arch.png
rename to docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-from-chaos-to-cutting-edge/old-batch-arch.png
diff --git a/docs-src/blog/bharatmlstack-history/post-one/online-feature-store-v0.png b/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-from-chaos-to-cutting-edge/online-feature-store-v0.png
similarity index 100%
rename from docs-src/blog/bharatmlstack-history/post-one/online-feature-store-v0.png
rename to docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-from-chaos-to-cutting-edge/online-feature-store-v0.png
diff --git a/docs-src/blog/bharatmlstack-history/post-one/schema.png b/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-from-chaos-to-cutting-edge/schema.png
similarity index 100%
rename from docs-src/blog/bharatmlstack-history/post-one/schema.png
rename to docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-from-chaos-to-cutting-edge/schema.png
diff --git a/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-lessons-from-first-gen/bms.png b/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-lessons-from-first-gen/bms.png
new file mode 100644
index 00000000..b397fc88
Binary files /dev/null and b/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-lessons-from-first-gen/bms.png differ
diff --git a/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-lessons-from-first-gen/index.md b/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-lessons-from-first-gen/index.md
new file mode 100644
index 00000000..6bc7f513
--- /dev/null
+++ b/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-lessons-from-first-gen/index.md
@@ -0,0 +1,149 @@
+---
+title: "Building Meesho’s ML Platform: Lessons from the First-Gen System (Part 2)"
+description: "Lessons from scaling Meesho's first-gen ML platform—building Inferflow for no-code feature retrieval, migrating from Cassandra to ScyllaDB, optimizing the Interaction Store with tiered storage, and cutting infra costs by 60% while hitting 1M QPS."
+authors: [bhawani, jigar, adarsha]
+slug: building-meeshos-mlplatform-lessons-from-first-gen
+date: 2023-4-10
+tags: [inferflow, interaction-store, mlplatform, meesho, bharatmlstack]
+---
+
+
+By late 2022, we had built something we were truly proud of—a real-time ML serving system with a DAG-based executor, a feature store, and an interaction store powering key ranking and personalization models. It was a major milestone, the culmination of months of effort from data scientists, ML engineers, and backend teams. Our system was live, and we were ready to push the boundaries of experimentation.
+And it worked. Mostly.
+But soon, cracks appeared. Every new model needed custom feature retrieval logic, DAGs became dense and unmanageable, and scaling turned into a constant firefight. Costs surged, and infra bottlenecks slowed experimentation. Our system worked, but it wasn’t built for scale.
+This is the story of how we tackled these challenges—building Inferflow for seamless feature retrieval, optimizing real-time infra, and cutting costs while scaling to millions of QPS.
+
+### The Cost of Success
+Every new Ranker model required its own feature set, often pulling from different entities. Each addition meant:
+
+- Adding new DAG nodes in IOP
+- Writing custom logic to fetch features from multiple sources (e.g., user, product, user × category)
+- Inferring intermediate features (e.g., extracting category from a product to fetch user × category data)
+- Optimizing I/O and dealing with the inevitable bugs
+
+What began as clean DAGs soon turned into a tangled web of cross-dependent graphs. Every experimentation cycle meant new nodes, new dependencies, and slower iterations.
+
+### Scaling Pains (and Cassandra’s Limits)
+At some point, we were hitting:
+
+- 250–300K reads/sec
+- 1M writes/sec (during lean hours)
+
+All of this ran on Cassandra. While its distributed architecture had been proven in production, operating large-scale clusters came with considerable infrastructure overhead. Our proof-of-concept (POC) demonstrated throughput of around 100K ops/sec, but as we scaled further, the challenges grew. Ensuring node health, optimizing compaction, and maintaining storage balance became increasingly demanding. We also observed latency spikes under heavy load, alongside a sharp increase in total cost of ownership.
+
+### Interaction Store Woes
+Our interaction store was another ticking time bomb:
+
+- 🚨 Clusters kept growing in size and cost
+- 🚨 Latency spikes became increasingly frequent
+- 🚨 The DMC proxy occasionally lost locality of nodes against shards, causing cross-node communication and degraded performance
+
+Each time this happened, we had to manually rebalance shards just to restore stable latency, making operations unsustainable at scale.
+
+### Silver Linings
+Despite the chaos, the system was live and delivering value:
+
+- Real-time infrastructure was in production
+- Costs dropped by 60–70% compared to offline personalization
+- New experiments rolled out faster and more successfully
+- User engagement metrics improved
+
+It wasn’t perfect. It was far from easy. But it worked—and that counted for a lot.
+
+### Round Two: Solving the Top 2 Bottlenecks
+With the first-gen system stretched to its limits, we stepped back. Conversations with data scientists and backend engineers revealed three recurring pain points:
+
+1. Coding feature retrieval logic for every new model was becoming unsustainable
+2. ML scale was exploding—bringing rising infra costs with it
+3. Real-time embedding search was the next big unlock
+
+We tackled them one by one—starting with the biggest pain point.
+
+#### Problem 1: No-Code Feature Retrieval for Model Inference
+We noticed a pattern: for personalized ranking, models needed features from:
+
+- ✅ Product
+- ✅ User
+- ✅ User × Category
+- ✅ Region, cohort, sub-category, etc.
+
+A key insight emerged: Entities that contribute features for a model always map back to the context entities.
+
+
+
+With this, we designed Inferflow, a graph-driven feature retrieval and model orchestration system:
+
+- 1️⃣ Inferflow takes a modelId and context IDs (e.g., userId, productIds)
+- 2️⃣ Loads a pre-defined feature retrieval graph from ZooKeeper
+- 3️⃣ Executes the graph to resolve entity relationships dynamically
+- 4️⃣ Outputs a 2D matrix of feature vectors
+
+💡 The impact?
+
+- 🚀 No more custom feature retrieval code—just graph updates in config
+- 🚀 Feature consistency across experiments
+- 🚀 Faster iteration cycles for ranking, fraud detection, and beyond
+
+Here’s a visual example that shows how this graph plays out during execution. We further extended the graph to call multiple models as needed:
+
+We built Inferflow in GoLang, using gRPC and Proto3 serialization for efficiency.
+
+#### Problem 2: Scaling Without Breaking the Bank
+With more ML use cases coming online, we needed to cut costs without compromising performance. We focused on:
+
+- 🔹 Online Feature Store
+- 🔹 Interaction Store
+
+#### Optimizing the Online Feature Store
+Our costs were concentrated in:
+
+- 📌 Database (Cassandra)
+- 📌 Cache (Redis)
+- 📌 Running Pods (Java services)
+
+1️⃣ Replacing Cassandra with ScyllaDB
+As we hit the operational limits of large Cassandra clusters, we transitioned to ScyllaDB, which offered a seamless drop-in replacement without major code changes. The switch brought significant benefits:
+
+- Throughput: Matched or exceeded Cassandra's performance under identical workloads, even under high concurrency.
+- Latency: Achieved consistently lower P99 latencies due to ScyllaDB's shard-per-core architecture and better I/O utilization.
+- Cost Efficiency: Reduced infra footprint by ~70% through better CPU and memory efficiency, eliminating the need for over-provisioned nodes.
+
+2️⃣ Finding the Right Cache
+To reduce backend load and improve response times, we benchmarked multiple caching solutions—Memcached, KeyDB, and Dragonfly—under real production traffic patterns. Dragonfly stood out due to its robust architecture and operational simplicity:
+
+- Data Skew Handling: Efficiently managed extreme key hotness and uneven access patterns without performance degradation.
+- Throughput: Delivered consistently high throughput, even with large object sizes and concurrent access.
+- Ease of Adoption: Acted as a drop-in Redis replacement with full protocol compatibility—no changes needed in application code or client libraries.
+
+3️⃣ Moving to GoLang for Cost-Efficient Serving
+Java services were memory-heavy—so we rewrote core services in GoLang. The results?
+
+✅ Memory usage dropped by ~80%
+✅ CPU utilization was significantly lower
+✅ Faster, more efficient deployments
+
+#### Optimizing the Interaction Store
+We realized that we only need a user’s interaction data in Redis when they open the app. So, we implemented a tiered storage approach:
+
+- 📌 Cold Tier (ScyllaDB)—Stores click, order, wishlist events
+- 📌 Hot Tier (Redis)—Loads a user’s past interactions only when they open the app
+
+Smart Offloading: We introduced an inactivity tracker to detect when a user session ends. At that point, Redis data was flushed back to Scylla, reducing unnecessary writes.
+
+
+#### Results
+
+- Online Feature Store hit 1M QPS for the first time during the 2023 Mega Blockbuster Sale—without breaking a sweat
+- Infra costs for Online Feature Store and Interaction Store dropped by ~60%
+
+#### The Catch: Our ML Hosting Hit a Hard Limit
+While planning for 2023 MBS, we ran into a critical scalability bottleneck:
+
+- ❌ Insufficient compute availability in our region for ML instances
+- ❌ Couldn’t provision enough nodes to handle real-time inference at scale
+
+This forced us to rethink where and how we hosted our models. The existing setup was great for prototyping—but it wasn’t built to handle the bursty, high-QPS demands of real-world production workloads.
+
+### Conclusion: From Firefighting to Future-Proofing
+What started as an ambitious experiment turned into a real-time ML infrastructure that powered millions of requests per second. We battled scaling pains, rethought feature retrieval with Inferflow, and rebuilt our infra stack for efficiency—driving down costs while improving experimentation velocity.
+But new challenges emerged. Our infrastructure could now handle scale, but our ML model hosting setup hit a hard limit. With compute availability bottlenecks threatening real-time inference, we faced a critical decision: how do we make model serving as scalable and cost-efficient as the rest of our stack? That’s the next piece of the puzzle—and the story of Part 3.
diff --git a/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-lessons-from-first-gen/interaction-str.png b/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-lessons-from-first-gen/interaction-str.png
new file mode 100644
index 00000000..99ddd4e9
Binary files /dev/null and b/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-lessons-from-first-gen/interaction-str.png differ
diff --git a/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-lessons-from-first-gen/mp-dag.png b/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-lessons-from-first-gen/mp-dag.png
new file mode 100644
index 00000000..4a13af56
Binary files /dev/null and b/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-lessons-from-first-gen/mp-dag.png differ
diff --git a/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-lessons-from-first-gen/mp-matrix.png b/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-lessons-from-first-gen/mp-matrix.png
new file mode 100644
index 00000000..44b21256
Binary files /dev/null and b/docs-src/blog/bharatmlstack-history/building-meeshos-mlplatform-lessons-from-first-gen/mp-matrix.png differ
diff --git a/docs-src/blog/bharatmlstack-history/episodic-memory-for-agents/bms.png b/docs-src/blog/bharatmlstack-history/episodic-memory-for-agents/bms.png
new file mode 100644
index 00000000..b397fc88
Binary files /dev/null and b/docs-src/blog/bharatmlstack-history/episodic-memory-for-agents/bms.png differ
diff --git a/docs-src/blog/bharatmlstack-history/episodic-memory-for-agents/index.md b/docs-src/blog/bharatmlstack-history/episodic-memory-for-agents/index.md
new file mode 100644
index 00000000..0cce0e1d
--- /dev/null
+++ b/docs-src/blog/bharatmlstack-history/episodic-memory-for-agents/index.md
@@ -0,0 +1,219 @@
+---
+title: "Beyond Vector RAG: Building Agent Memory That Learns From Experience."
+description: "Current agent memory is just search. We built an episodic memory system that tracks outcomes, forms causal links, extracts reasoning heuristics, and actually learns from failure — without retraining the model."
+slug: episodic-memory-for-agents
+authors: [adarsha]
+date: 2026-02-19
+tags: [ai-agents, memory, architecture, llm, episodic-memory]
+---
+
+Agent memory has come a long way. Persistent context, vector retrieval, knowledge graphs — the building blocks are real and getting better fast.
+
+But most of what we call "memory" today is still closer to search: chunk text, embed it, retrieve whatever looks similar at query time. That works well for recalling facts and preferences. It starts to break down when you need an agent to recall what happened last time, learn from a mistake, or avoid repeating a failed approach.
+
+We are trying to experiment something different. An episodic memory system where a frozen LLM — same weights, no retraining — produces increasingly better decisions over time because the memory feeding it context is continuously evolving.
+Then we tested it. The results were interesting.
+
+
+
+
+## The Gap Nobody Talks About
+
+Here's a scenario every engineering team has encountered: AI agent hits a Redis connection pool exhaustion issue. It misdiagnoses it as a database problem. You correct it. Next week, a different service has the exact same failure pattern. The agent makes the exact same mistake.
+
+Why? Because LLMs don't learn at inference time. Corrections adjust behavior within a conversation. Once the session ends, the lesson is gone. The model weights haven't changed. The next conversation starts from zero.
+
+Current "memory" systems don't fully address this. They store facts — user preferences, document chunks, conversation summaries. But facts aren't experience. Knowing that "Redis connection pools can exhaust under load" is different from remembering "last time I saw 500 errors under load, I assumed it was the database, I was wrong, it was actually the connection pool, and here's the correction I received."
+
+The first is a fact. The second is an episode. The difference matters.
+
+## What's Wrong With Vector RAG as Memory
+
+We identified five structural gaps in how current agent frameworks handle memory:
+
+**No concept of time.** Two events are either semantically similar or they're not. The system can't represent "this happened after that" without distorting similarity scores. An agent can't reason about sequence or causality.
+
+**No concept of situation.** A production incident and a design review might use the same technical vocabulary. Flat vector search can't distinguish them. Your agent retrieves planning notes when it should be retrieving incident postmortems.
+
+**No outcome tracking.** The system stores *what happened* but not *whether it worked*. A failed approach and a successful one are equally retrievable. The agent has no way to prefer strategies that worked over strategies that didn't.
+
+**Summaries destroy evidence.** Summarization-based memory compresses experience but discards the reasoning chain. The agent loses the ability to explain *how* it arrived at a conclusion. The audit trail is gone.
+
+**No causal links.** Each memory chunk is independent. There's no way to express that incident A caused decision B, which led to outcome C, which was corrected by approach D. Without this structure, the agent can't traverse chains of reasoning.
+
+These gaps compound. As an agent accumulates more experience, flat vector memory gets noisier, more contradictory, and less useful. The system degrades precisely when it should be improving.
+
+## The Architecture: Episodic Memory
+
+We are building a memory system modeled on how human episodic memory works — not as a metaphor, but as an engineering specification.
+
+The system has four layers:
+
+### Layer 1: Immutable Timeline
+
+Every piece of agent experience is recorded as an append-only timeline entry. Each entry carries a semantic embedding (what it means), a timestamp (when it happened), and a state label (what situation the agent was in — debugging, planning, code review, incident response). Entries are never modified, never deleted, never summarized. This is the source of truth.
+
+### Layer 2: Episode Segmentation
+
+The system watches the timeline and detects when one coherent unit of experience ends and another begins — via state transitions, semantic shifts, temporal gaps, or explicit signals. Each episode is a reference into the timeline (not a copy) with a generated summary, an outcome (SUCCESS, FAILURE, PARTIAL, UNKNOWN), decisions made, assumptions held, and corrections received.
+
+The outcome field is the most important thing that doesn't exist in any current memory system. Without it, you can't learn from mistakes.
+
+### Layer 3: Episodic Graph
+
+Episodes are connected through typed, weighted links: CAUSED_BY, LED_TO, RETRY_OF, LEARNED_FROM, CONTINUATION, CONTRADICTED. Over time, this forms a directed graph that enables traversal by meaning and causality. You can follow the chain: "this incident caused that investigation, which led to a failed fix, which was corrected by this approach."
+
+### Layer 4: Generalized Facts
+
+When multiple episodes exhibit consistent patterns, the system extracts reasoning heuristics: "When services fail immediately after deployment with no traffic change, investigate configuration errors before connection pool problems." Facts are versioned, never overwritten, and maintain links back to supporting and contradicting episodes. When contradicting evidence accumulates, confidence decreases. When confidence drops below a threshold, the fact is revised — but the old version is preserved.
+
+The LLM sits above all four layers. At query time, the system assembles structured context — relevant episodes with outcomes, applicable facts with confidence scores, causal narratives — and passes it to the LLM for reasoning. The model reasons over structured memory. It doesn't store or manage memory.
+
+### The Reinforcement Loop
+
+This is where it comes together:
+
+1. Agent reasons using retrieved episodes and facts
+2. Outcome is detected (CI pass/fail, user correction, test result)
+3. New episode is created with outcome tracking
+4. Links are created between the retrieved episodes and the new episode
+5. Facts are reinforced (if outcome aligned) or contradicted (if outcome conflicted)
+6. If the decision was wrong and corrected, a LEARNED_FROM link is created
+
+The model weights never change. The memory structure evolves continuously. A frozen LLM produces better decisions over time because it receives better context from richer memory.
+
+## The Experiment
+
+We built the full system in Python (~1,000 lines) and tested it head-to-head against a baseline flat-vector RAG agent across a 9-round synthetic debugging scenario. Both agents used the identical LLM (Claude Sonnet 4) for reasoning. The only variable was the memory system.
+
+The scenario was designed to test five capabilities:
+
+| Round Type | What It Tests | Rounds |
+|---|---|---|
+| LEARN | Can the agent build experience from failures? | 1, 2, 4 |
+| RED HERRING | Can the agent resist applying a pattern when it doesn't fit? | 3 |
+| TEST | Can the agent apply learned patterns to new services? | 5, 6 |
+| SUBTLE | Can the agent generalize to different symptoms, same root cause? | 7 |
+| CORRECTION | After being corrected, does the agent adapt? | 8, 9 |
+
+Rounds 1-4 build experience: three connection pool failures across different services, plus one red herring (a deployment config error that *looks* like a connection pool issue). Rounds 5-7 test whether the agent applies the learned pattern to unfamiliar services and subtle symptom variations. Rounds 8-9 are the critical test: the agent is corrected after misdiagnosing a deployment-correlated error, then tested on a near-identical scenario to see if it adapts.
+
+## Results
+
+### Decision Accuracy
+
+| Round | Type | Episodic Agent | Baseline Agent |
+|---|---|---|---|
+| 1 | LEARN | ✗ | ✓ |
+| 2 | LEARN | ✓ | ✓ |
+| 3 | RED HERRING | ✗ | ✗ |
+| 4 | LEARN | ✓ | ✓ |
+| 5 | TEST | **✓** | ✗ |
+| 6 | TEST | **✓** | ✗ |
+| 7 | SUBTLE | **✓** | ✗ |
+| 8 | CORRECTION | ✓ | ✓ |
+| 9 | CORRECTION | ✓ | ✓ |
+| **Total** | | **7/9 (78%)** | **5/9 (56%)** |
+
+The episodic agent won 7-5. A 40% relative improvement in decision accuracy using the exact same LLM.
+
+### Where the Gap Opened
+
+The episodic agent's advantage concentrated in exactly the rounds designed to test memory quality:
+
+**Rounds 5-6 (pattern application):** The episodic agent cited 4 past failure episodes with connection pool exhaustion as root cause, complete with correction annotations. It correctly identified pool exhaustion in new services. The baseline retrieved disconnected chunks and suggested checking timeout configurations — a pattern it picked up from the Round 3 red herring.
+
+**Round 7 (subtle symptoms — latency increase, no errors):** Both agents had the same evidence available. The episodic agent's retrieval surfaced a diverse set of episodes (thanks to MMR diversity filtering) including the Redis pool exhaustion from Round 6, which primed it to recognize that latency without errors can still be pool contention. The baseline defaulted to "check recent config changes."
+
+**Round 9 (adaptation after correction):** This is the result we're most proud of. Look at the episodic agent's reasoning:
+
+> *"Episode 1 directly parallels this situation — errors spiking immediately after a deployment (v2.4.1 then, v3.1.0 now) with no traffic change. In that case, the root cause was a database migration that dropped an index. The generalized fact confirms that deployment-related issues with immediate onset after version changes are more likely caused by configuration errors or missing dependencies than by connection pool problems."*
+
+It cited a specific past episode by analogy, quoted a generalized fact, and explained *why* this situation matches the deployment pattern rather than the connection pool pattern. The baseline gave a vaguer assessment.
+
+### Retrieval Quality
+
+This is where the structural difference is most visible:
+
+| Metric | Episodic Agent | Baseline Agent |
+|---|---|---|
+| Retrieved items with explicit outcome labels | **100%** | 25% |
+| Correct pattern applications (Rounds 4-7) | **4/4** | 1/4 |
+| False positives (Rounds 8-9) | **0** | 0 |
+
+Every item the episodic agent retrieved carried a structured outcome label (SUCCESS or FAILURE) with correction details. Only 25% of the baseline's chunks contained any outcome information — and those were incidental text mentions, not structured labels.
+
+The episodic agent correctly applied the connection pool pattern in all four rounds where it was the root cause, and correctly avoided it in both rounds where it wasn't. The baseline applied it correctly once.
+
+## What Didn't Work
+
+Two things didn't work as anticipated:
+
+**Round 3 (red herring):** Both agents failed. The symptoms looked like connection pool issues, but the root cause was a deployment config change. At this point, the episodic agent had only seen connection pool episodes — it had no counter-evidence for deployment-correlated errors. You can't distinguish patterns you've only seen one side of. After Round 8 introduced a correction, the agent successfully avoided this mistake in Round 9.
+
+**Fact quality variance.** Some extracted facts were specific and actionable ("Deployment-related issues with immediate onset are more likely configuration errors"). Others were vague ("Initial symptom-based diagnosis often leads to misidentifying the root cause"). A production system needs a usefulness filter, not just a confidence score.
+
+## What This Means
+
+The most important finding isn't the accuracy improvement. It's that the reinforcement loop closes without retraining.
+
+In the POC, we observed:
+
+- Rounds 1-4: Agent encounters failures, episodes recorded with outcomes and corrections
+- After Round 4: Fact extracted — "Connection pool exhaustion is a common root cause under load"
+- Rounds 5-7: Agent applies the pattern with increasing confidence (fact support count grows)
+- Round 8: Agent encounters a deployment error, correctly identifies it as config, gets corrected
+- After Round 8: New fact — "Deployment-related issues with immediate onset are more likely configuration errors"
+- Round 9: Agent receives near-identical scenario, correctly avoids connection pool pattern, cites the Round 8 correction
+
+The model didn't change. The memory evolved. That's the whole point.
+
+## How It Compares to Existing Solutions
+
+Agent memory is a fast-moving space with several strong systems, each solving a different slice of the problem:
+
+**Mem0** excels at persistent personalization — extracting user preferences, managing session context, and reducing token costs through intelligent compression. It's the most production-ready memory layer available and integrates with nearly every agent framework. Its focus is on remembering about users and conversations rather than learning from task-level outcomes, which is a different problem than the one we're exploring here.
+
+**Zep/Graphiti** is doing some of the most interesting work in temporal knowledge graphs. Their bi-temporal model — tracking both when an event occurred and when it was ingested — addresses a real structural gap in how agent memory handles changing facts over time. Their episode and entity subgraphs share some philosophical DNA with our approach. Where our work diverges is in outcome tracking and reinforcement: we're specifically focused on whether a decision worked, and using that signal to update memory structure.
+
+**Letta (formerly MemGPT)** pioneered self-editing memory — giving the LLM tools to manage its own memory blocks. This is a powerful paradigm, and their recent work on "Context Repositories" and sleep-time compute suggests they're actively pushing toward agents that learn over time. Their team has been transparent that experiential learning is an unsolved problem, which is part of what motivated our exploration.
+
+**MemRL (Jan 2026 paper)** is the closest to our work academically. It shares the core insight of decoupling stable LLM reasoning from plastic, evolving memory. Their approach uses reinforcement learning to assign utility Q-values to memories, which is elegant but requires training a value function. Our approach is purely structural — no training step, no Q-values, just graph evolution and LLM-based reasoning over outcomes.
+
+
+The common thread: most existing systems focus on knowledge persistence — remembering facts, preferences, and conversation history across sessions. The problem we're exploring is experiential learning — tracking whether past decisions worked, forming causal chains between episodes, and extracting reasoning heuristics that improve over time. These are complementary capabilities that would be needed by an ideal production system.
+
+## Try It Yourself
+
+The prototype is available in our experiments directory:
+
+```
+experiments/episodic-memory-prototype/
+├── memory/ # Timeline, encoder, episodes, graph, facts, retriever, reinforcer
+├── agent/ # Episodic memory agent
+├── baseline/ # Flat vector RAG agent (comparison)
+├── simulator/ # 9-round debugging scenario
+├── eval/ # Head-to-head comparison + scoring
+└── tests/
+```
+
+To run the comparison:
+
+```bash
+cd experiments/episodic-memory-prototype
+python -m venv .venv && source .venv/bin/activate
+pip install -r requirements.txt
+export ANTHROPIC_API_KEY=sk-ant-...
+python -m eval.compare
+```
+
+Without an API key, it runs in heuristic mode (keyword-based decisions). With a key, both agents use Claude Sonnet for reasoning — that's where the quality gap becomes visible.
+
+
+## Conclusion
+This is a 9-round synthetic scenario we designed. It demonstrates the poc architecture works end-to-end and shows where episodic memory provides qualitatively different reasoning. It is not a peer-reviewed benchmark and should not be interpreted as a statistically rigorous claim. We're publishing the prototype so others can reproduce and extend the evaluation.
+If this sparks interest do trigger github discussion.
+
+---
+
+*The episodic memory prototype is available in `BharatMLStack` repo at `/experiments/episodic-memory-prototype`*
diff --git a/docs-src/blog/bharatmlstack-history/llm-inference-optimization/bms.png b/docs-src/blog/bharatmlstack-history/llm-inference-optimization/bms.png
new file mode 100644
index 00000000..b397fc88
Binary files /dev/null and b/docs-src/blog/bharatmlstack-history/llm-inference-optimization/bms.png differ
diff --git a/docs-src/blog/bharatmlstack-history/llm-inference-optimization/index.md b/docs-src/blog/bharatmlstack-history/llm-inference-optimization/index.md
new file mode 100644
index 00000000..a19550e8
--- /dev/null
+++ b/docs-src/blog/bharatmlstack-history/llm-inference-optimization/index.md
@@ -0,0 +1,120 @@
+---
+title: "LLM Inference Optimization Techniques: Engineering Sub-Second Latency at Scale"
+description: "A practical guide to the optimization techniques behind sub-second LLM inference—covering paged KV caching, INT4 AWQ and FP8 quantization, kernel fusion, inflight batching, parallelism strategies, and speculative decoding, with production benchmarks on L4 and A100 GPUs."
+authors: [jaya]
+slug: llm-inference-optimization-sub-sec-latency
+date: 2025-6-2
+tags: [llm, vllm, tensorrt-llm, mlplatform, meesho, bharatmlstack]
+---
+
+
+Raw execution of Large Language Models is inherently expensive and memory-intensive. To achieve sub-second latency and high throughput, we implement a multi-layered optimization strategy that targets the entire inference stack—from memory management to kernel execution.
+
+## 1. Advanced Memory Management: Paged & Prefix KV Caching
+
+The most significant bottleneck in LLM inference is not always compute, but memory bandwidth—specifically managing the Key-Value (KV) cache.
+
+### Paged KV caching
+
+Standard caching suffers from fragmentation. We use **Paged KV caching**, which operates similarly to an operating system's virtual memory: the KV cache is divided into non-contiguous blocks. This lets us serve larger batch sizes without running out of memory.
+
+### KV cache quantization
+
+To further maximize available memory, we implement **KV cache quantization** (e.g., FP8). By compressing stored attention keys and values from 16-bit to 8-bit, we nearly double the effective context window capacity of the GPU, allowing longer conversations or larger batches without materially degrading quality.
+
+### Prefix caching (the "voice bot" optimizer)
+
+For use cases like GenAI voice bots where the system prompt (e.g., "You are a helpful assistant...") is static across thousands of requests, we enable **prefix caching**.
+
+- **Impact**: By reusing pre-computed KV states for common prefixes, we achieve a cache hit rate of ~90%. This reduces **Time To First Token (TTFT)** by skipping redundant computation of the system prompt.
+
+## 2. Aggressive Quantization (INT4 AWQ & FP8)
+
+Running models in their native 16-bit precision (BF16) restricts maximum batch size and throughput. We use quantization to shrink model weights without sacrificing accuracy.
+
+### INT4 AWQ (Activation-aware Weight Quantization)
+
+For the Llama 3 family, we use **AWQ** to compress weights to 4 bits. This reduces model size by ~75%, allowing larger models to fit into L4 GPU memory and significantly improving token generation speed.
+
+### FP8 precision
+
+For NVIDIA Hopper (H100) architectures, we are exploring **FP8 quantization**, leveraging native FP8 tensor cores to accelerate matrix multiplications while maintaining a higher dynamic range than integer quantization.
+
+- **Verification**: We validate quantized models by comparing dot-product similarity of embeddings against the FP16 baseline, consistently achieving **>99% similarity**.
+
+## 3. Kernel Fusion & Custom Plugins
+
+To minimize overhead from launching thousands of small GPU operations, we fuse them into monolithic kernels using NVIDIA TensorRT plugins.
+
+- **Flash attention & FMHA**: We enable **Fused Multi-Head Attention (FMHA)** combined with flash attention to reduce memory reads/writes.
+- **GEMM plugins**: We use specialized **GEMM** plugins to accelerate transformer linear layers.
+- **Removing input padding**: Instead of padding short sequences to match the longest, we remove input padding so the GPU processes only valid tokens.
+
+## 4. Inflight (Continuous) Batching
+
+Traditional static batching waits for all requests in a batch to finish before returning results—so one long response delays everyone else.
+
+We implement **inflight batching**: as soon as one request completes, its slot is freed and filled by a new request from the queue. This keeps GPUs saturated and decouples latency of short queries from long ones.
+
+## 5. Parallelism Strategies: Scaling Beyond One GPU
+
+For large models (e.g., 70B+ parameters) that cannot fit into the VRAM of a single GPU, we use parallelism strategies.
+
+- **Tensor parallelism (TP)**: Split weight matrices across multiple GPUs (e.g., 4× L4 or 8× A100). Each GPU computes a shard and outputs are reduced at every layer.
+- **Pipeline parallelism (PP)**: Split model layers across GPUs to pipeline compute (e.g., while one GPU computes later layers for Request A, another starts early layers for Request B).
+
+## 6. Speculative Decoding
+
+To reduce inter-token latency (ITL), we explore **speculative decoding**.
+
+- **Mechanism**: A smaller, faster "draft" model speculatively generates a short token sequence (e.g., 5 tokens).
+- **Verification**: The larger target model verifies those tokens in one parallel forward pass. If correct, we effectively generate multiple tokens per large-model step; if not, we discard and regenerate. This is effective for predictable text, improving perceived generation speed.
+
+## Few Benchmarks
+
+Below are a couple of representative use cases and performance numbers.
+
+### Search query rewriting
+
+- **LLM**: Fine-tuned llama-3.2-1B
+- **Input & output token length**: ~10–20
+- **Response type**: Non-streaming
+
+| Inference runtime | Hardware | Max requests/sec | Max p99 latency |
+| --- | --- | ---: | ---: |
+| TensorRT-LLM | 4 × L4 GPUs (multi-GPU) | 1000 | 95 ms |
+| TensorRT-LLM | 1 × A100 40 GB GPU | 1000 | 69 ms |
+
+### Voice bot query
+
+- **LLM**: Llama-3.1-8B
+- **Input token length**: ~1900–2000
+- **Output token length**: ~200
+- **Response type**: Streaming
+
+| Inference runtime | Concurrency | p99 TTFT (ms) | p99 ITL (ms) | Token throughput (tokens/sec) | Request throughput (req/sec) | Hardware |
+| --- | ---: | ---: | ---: | ---: | ---: | --- |
+| TensorRT-LLM | 1 | 36.27 | 22.78 | 45.66 | 0.23 | L4 |
+| TensorRT-LLM | 2 | 49.81 | 23.21 | 89.37 | 0.45 | L4 |
+| TensorRT-LLM | 4 | 55.33 | 36.62 | 153.39 | 0.78 | L4 |
+| TensorRT-LLM | 8 | 66.5 | 39.11 | 279.88 | 1.47 | L4 |
+| TensorRT-LLM | 16 | 131.8 | 30.39 | 547.8 | 2.77 | L4 |
+| TensorRT-LLM | 32 | 277.22 | 48.02 | 925.7 | 4.78 | L4 |
+| TensorRT-LLM | 64 | 498.52 | 71.62 | 1,164.40 | 6.2 | L4 |
+| TensorRT-LLM | 128 | 677.31 | 120.37 | 1,445.18 | 7.69 | L4 |
+| TensorRT-LLM | 256 | 1,926.31 | 216.88 | 1,600.81 | 8.52 | L4 |
+| TensorRT-LLM | 1 | 21.17 | 9.24 | 130.05 | 0.68 | A100 |
+| TensorRT-LLM | 2 | 25.78 | 9.21 | 264.5 | 1.35 | A100 |
+| TensorRT-LLM | 4 | 28.52 | 10.99 | 437.69 | 2.27 | A100 |
+| TensorRT-LLM | 8 | 34.4 | 12.61 | 760.49 | 3.96 | A100 |
+| TensorRT-LLM | 16 | 68.03 | 14.32 | 1,343.80 | 7.01 | A100 |
+| TensorRT-LLM | 32 | 185.96 | 16.82 | 2,287.30 | 11.92 | A100 |
+| TensorRT-LLM | 64 | 136.87 | 21.17 | 3,625.22 | 18.89 | A100 |
+| TensorRT-LLM | 128 | 463.78 | 34.15 | 4,456.51 | 23.24 | A100 |
+| TensorRT-LLM | 256 | 890.12 | 59.18 | 5,188.24 | 27.05 | A100 |
+
+## Conclusion
+
+High-performance LLM inference is fundamentally a systems engineering problem: memory efficiency, kernel execution, batching strategy, and parallelism determine real-world latency and throughput. Techniques such as paged KV caching, aggressive quantization, kernel fusion, and inflight batching improve GPU utilization while reducing latency and memory pressure.
+
+These optimizations enable the platform to deliver sub-second responses, sustain high concurrency, and efficiently serve both lightweight and long-context workloads. By continuously optimizing across the full inference stack, we keep LLM serving scalable, cost-efficient, and production-ready for real-time AI applications.
diff --git a/docs-src/blog/bharatmlstack-history/llm-inferencing-platform/bms.png b/docs-src/blog/bharatmlstack-history/llm-inferencing-platform/bms.png
new file mode 100644
index 00000000..b397fc88
Binary files /dev/null and b/docs-src/blog/bharatmlstack-history/llm-inferencing-platform/bms.png differ
diff --git a/docs-src/blog/bharatmlstack-history/llm-inferencing-platform/index.md b/docs-src/blog/bharatmlstack-history/llm-inferencing-platform/index.md
new file mode 100644
index 00000000..ac16ef0f
--- /dev/null
+++ b/docs-src/blog/bharatmlstack-history/llm-inferencing-platform/index.md
@@ -0,0 +1,201 @@
+---
+title: "Designing a Production-Grade LLM Inference Platform: From Model Weights to Scalable GPU Serving"
+description: "A deep dive into building a production-grade LLM inference platform—covering the full LLMOps lifecycle from model onboarding and automated compilation to multi-engine serving with TensorRT-LLM, vLLM, and Dynamo, along with cold-start mitigation and LLM-specific observability."
+authors: [jaya]
+slug: multi-engine-llm-inferencing-platform
+date: 2025-3-29
+tags: [llm, vllm, tensorrt-llm, mlplatform, meesho, bharatmlstack]
+---
+
+
+Serving large language models in production introduces new challenges across infrastructure, performance optimization, and operational lifecycle management. The LLM Inference Platform addresses these challenges by providing a unified system for deploying and managing open-source and fine-tuned LLMs at scale.
+
+The platform implements a complete LLMOps lifecycle — from model registration and automated compilation to deployment, runtime optimization, and monitoring. Designed as a self-service environment, users can onboard models directly from open repositories such as Hugging Face or upload custom fine-tuned models, and deploy them using a single-click workflow with no manual infrastructure or configuration steps required.
+
+In addition to fully automated deployment, the platform allows users to select and apply custom inference optimization techniques — such as quantization strategies, batching configurations, and runtime-specific performance enhancements — enabling teams to balance latency, throughput, and cost based on their use case. The goal is to reduce operational friction while enabling high-performance, production-grade LLM inference.
+
+## Why LLM Inference Is not just bigger ML model serving
+
+Large language model (LLM) inference introduces a fundamentally different set of challenges compared to traditional machine learning inference. While classical ML models typically perform a single forward pass to produce a fixed prediction, LLMs operate as autoregressive systems, generating outputs token by token based on previously generated context. This difference dramatically changes how inference systems must be designed, optimized, and scaled.
+
+### Autoregressive Generation and Sequential Computation:
+
+Unlike traditional models such as classifiers or recommenders — where inference cost is relatively constant — LLMs generate responses incrementally. Each new token depends on all previously generated tokens, making inference inherently sequential and dynamic. This means latency and compute requirements vary significantly depending on prompt length and output size, introducing complexity in scheduling and resource allocation.
+Because tokens cannot be generated fully in parallel during decoding, GPUs may become underutilized without specialized batching and scheduling strategies. This has led to the development of dedicated LLM inference engines optimized for token-level execution.
+
+### Prefill and Decode Phases:
+
+LLM inference typically consists of two distinct stages:
+
+- Prefill phase — the model processes the input prompt and builds internal representations. This stage is compute-heavy and highly parallelizable.
+- Decode phase — the model generates tokens sequentially, predicting one token at a time using previously generated context.
+
+The decode stage often becomes memory-bound rather than compute-bound, which creates new performance bottlenecks compared to traditional ML workloads.
+
+### Context Management and KV Caching:
+
+Another fundamental difference lies in how LLMs maintain context. Transformer-based models rely on attention mechanisms that require access to past token representations. To avoid recomputing these representations repeatedly, inference engines use key-value (KV) caching, which stores intermediate activations from previous tokens.
+KV caching significantly improves performance by eliminating redundant computation, but it introduces new challenges:
+
+- Memory consumption grows with sequence length and batch size
+- GPU memory becomes a critical bottleneck
+- Efficient memory management becomes essential for scaling concurrent requests
+
+This tradeoff between compute efficiency and memory usage is unique to LLM inference workloads.
+
+### Dynamic and Irregular Workloads:
+
+Traditional ML inference typically operates on fixed-size inputs with predictable latency. In contrast, LLM requests vary widely in prompt length, output length, and runtime behavior. As a result:
+
+- Batch sizes must be dynamic rather than static
+- Requests may enter and leave batches asynchronously
+- Scheduling systems must continuously rebalance workloads to maximize GPU utilization
+
+These characteristics require specialized serving architectures that differ significantly from standard ML serving pipelines.
+
+### Streaming and User Experience Constraints:
+
+Another distinguishing factor is the expectation of real-time streaming responses. Instead of returning a single output, LLM systems often stream tokens to users as they are generated.
+Because of these differences — sequential generation, growing memory requirements, dynamic workloads, and streaming constraints — LLM inference cannot be treated as a simple extension of existing ML serving systems. Production platforms must incorporate specialized runtime engines, advanced optimization techniques, and observability tailored specifically to LLM workloads.
+
+## LLMOps: High-Level Architecture
+
+
+
+The LLM Inference Framework is designed as a fully automated, end-to-end system for deploying and operating open-source and fine-tuned large language models at scale. The architecture abstracts the complexity of model optimization, hardware selection, deployment, and runtime management into a unified workflow that enables users to move from raw model weights to production-ready inference endpoints with minimal manual intervention.
+
+Our LLM Inference Framework is architected not just as a serving engine, but as a complete lifecycle management system. As illustrated in the high-level design below, the platform automates the journey of a model through seven distinct stages, ensuring reproducibility, performance, and scalability.
+
+1. Onboarding & Registration (The Source of Truth)
+
+ The lifecycle begins with the Data Scientist or engineer.
+
+ - Model Ingestion: Users onboard models—whether open-source (Hugging Face, NeMo) or internally fine-tuned—via the Truffle Box SDK/UI.
+ - LLM + Prompt Registry: Unlike traditional systems that only track model weights, our registry is a unified control plane. It stores both the Model Artifacts and the Prompt Templates. This allows Data Scientists to register and version-control prompts (e.g., "customer_support_v2") independently of the application code.
+
+2. The "Black Box" Build Engine
+
+ Once a model is registered, the Automated LLM Compiler + Quantizer Module kicks off a background job on ephemeral GPU resources.
+
+ - Transformation: The raw model is converted into a TRT-LLM Checkpoint.
+ - Quantization: The system automatically applies quantization algorithms (like INT4 AWQ or FP8) to reduce memory footprint.
+ - Engine Building: Finally, it compiles a highly optimized TRT Engine specifically tuned for the target hardware.
+
+3. Intelligent Profiling & Validation
+
+ Before deployment, the new engine passes through the Hardware & Inference Runtime Profiler.
+
+ - Benchmarking: This module empirically tests the engine against various hardware configurations (L4 vs. A100) and runtimes (TRT-LLM vs. vLLM).
+ - Optimization: It recommends the optimal configuration that meets latency SLAs (Time-To-First-Token) while minimizing cost.
+
+4. Smart Artifact Generation & Distribution
+
+ To solve the Kubernetes "Cold Start" problem, the LLM Serving Artifacts Generation module packages the model using a bifurcated strategy:
+
+ - Standard Models: Artifacts are uploaded to Cloud Storage (GCS) and downloaded by pods at startup.
+ - Very Large Models: For massive models (>8GB) where network downloads are too slow, the system pre-caches the model onto Secondary Boot Disks. These disks are attached directly to new GPU nodes during autoscaling, eliminating download wait times.
+
+5. Image Streaming & Deployment
+
+ Simultaneously, the inference runtime container images are pulled from the Artifact Registry.
+
+ - Image Streaming: We utilize container image streaming to allow pods to start initializing while the massive Triton/Dynamo container layers are still downloading, further shaving seconds off the startup time. link
+
+6. The Inference Runtime (Kubernetes)
+
+ The workload lands on Kubernetes with Autoscaling.
+
+ - Dynamic Backends: Depending on the profile generated in Stage 3, the pod initializes either TensorRT-LLM (for throughput) or vLLM (for flexibility), or spins up a Dynamo worker for distributed inference.
+ - Data Loading: The pod either downloads the model from Cloud Storage or mounts the pre-warmed Secondary Boot Disk ("Pull from Disk").
+
+7. Client Interaction & Observability
+
+ Finally, the LLM Inference Client executes the request.
+
+ - Prompt Injection: The client pulls the specific prompt template ID from the Registry, ensuring the exact versioned instructions are used.
+ - Streaming Response: The request is sent via gRPC, and tokens are streamed back to the user in real-time.
+
+8. Observability: Monitoring the Pulse of GenAI
+
+ In traditional microservices, success is measured by CPU utilization and request latency (p99). For Large Language Models, these metrics are insufficient. A user doesn't care if the GPU is at 80% utilization; they care about how fast the first word appears and how smoothly the rest of the sentence follows.
+
+ To capture the true user experience, our platform instrumentation focuses on three critical LLM-specific metrics:
+
+ 1. Time to First Token (TTFT)
+ - Definition: TTFT measures the time elapsed from the moment a request is received until the very first token is generated and streamed back to the user.
+ - Why it matters: This represents the "Prefill Phase" latency—the time the model takes to process the input prompt and load weights. A high TTFT makes the application feel unresponsive or "hung."
+ - Optimization: We closely monitor TTFT to ensure our Prefix Caching is effective (aiming for high cache hitrates), which drastically lowers this metric by skipping redundant prompt processing.
+
+ 2. Inter-Token Latency (ITL)
+ - Definition: ITL measures the average time interval between the generation of consecutive tokens during the "Decode Phase".
+ - Why it matters: This defines the "perceived speed" of reading. Even if the first token is fast (low TTFT), high ITL makes the text generation look "jerky" or slow to the user.
+ - Benchmarks: In our testing with Llama 3.1, we track p99 ITL to ensure it stays below human reading speeds to maintain a natural conversational flow.
+
+ 3. Token Throughput vs. Request Throughput
+ - We distinguish between two types of throughput to balance system efficiency with user load:
+ - Token Throughput (tokens/sec): The total number of tokens generated across all concurrent requests. This measures the raw compute efficiency of the GPU and the effectiveness of batching.
+ - Request Throughput (req/sec): The number of distinct user queries served per second. We use this to determine autoscaling thresholds, ensuring we scale out before the queue depth impacts ITL.
+
+ 4. The Monitoring Stack
+ - Real-time Dashboards: We utilize Grafana to visualize these streaming metrics in real-time, allowing on-call engineers to spot "slow generation" incidents that generic "500 error" alerts would miss.
+ - Request Tracing: Since Triton Inference Server does not log request payloads by default, we integrate a Helix Client to asynchronously publish request logs to Log Tables. This allows us to trace a specific "slow" request back to its prompt to understand if a complex input caused the latency spike.
+
+## Supported Inference backends (TensorRT LLM, Dynamo & vLLM)
+
+Tailored for the Use Case: We do not believe in a "one-size-fits-all" approach to inference. Different use cases—whether a real-time voice bot requiring ultra-lowsub-second latency or a massive reasoning task requiring huge context windows—demand different runtime characteristics. Our platform is designed to be runtime-agnostic, allowing us to automatically select and tailor the best engine based on the specific requirements of the application:
+
+1. TensorRT-LLM: The High-Performance Standard
+
+ Suitable for: High-throughput production workloads where latency is critical (e.g., customer support chat, real-time voice bots).
+
+ TensorRT-LLM serves as our default backend for these scenarios. Our internal benchmarks on Llama 3.1 and 3.2 models demonstrated that a tuned TensorRT-LLM engine significantly outperforms standard runtimes, especially when utilizing INT4 AWQ and FP8 quantization .
+
+ Key optimizations we tailor for these high-load cases include:
+
+ - Optimized execution via TensorRT engine compilation
+ - Quantization-aware execution for reduced memory usage and improved throughput
+ - Inflight Batching: Allowing requests to be processed continuously without waiting for the entire batch to finish, drastically improving GPU utilization .
+ - Custom Plugins: Enabling specific NVIDIA plugins like the GEMM plugin and GPT Attention plugin to accelerate matrix multiplications and attention mechanisms .
+
+2. Dynamo: Distributed Inference for Reasoning Models
+
+ Suitable for: Very large "reasoning" models (70B+) or scenarios requiring massive context windows where a single GPU's memory is insufficient.
+
+ For these memory-bound tasks, we utilize Dynamo, a low-latency distributed inference framework . Unlike monolithic servers, Dynamo disaggregates the inference process to scale resources horizontally:
+
+ - KV Aware Routing: A specialized router directs requests to workers that already hold the relevant Key-Value (KV) cache, minimizing redundant computation .
+ - Prefill vs. Decode Split: The workload is divided into Prefill Workers (processing the prompt) and Decode Workers (generating tokens), allowing us to scale the compute-heavy "reading" phase independently from the memory-heavy "writing" phase .
+ - Distributed execution across multiple GPU resources
+
+3. vLLM: The Flexible Baseline
+
+ Suitable for: Rapid prototyping, testing new model architectures, or low-traffic internal tools where ease of deployment outweighs raw throughput.
+
+ While TensorRT-LLM is optimized for maximum speed, vLLM provides a robust and flexible baseline .
+
+ - High throughput through dynamic batching and efficient memory utilization
+ - Paged KV cache management for handling long contexts and concurrent requests
+ - Strong support for open-source model ecosystems
+ - Rapid Adoption: It allows us to onboard new model architectures immediately without waiting for a custom TensorRT build.
+ - Benchmarking Insight: In our internal tests, vLLM provided a strong baseline but often lacked the specific max-token optimizations present in our custom TRT engines . We use it strategically for initial testing before committing to a full TensorRT optimization pipeline.
+
+## Conclusion
+
+Large language model inference introduces a fundamentally new class of infrastructure challenges—where performance is governed not just by raw compute, but by memory efficiency, intelligent scheduling, runtime specialization, and lifecycle automation. Unlike traditional ML serving, LLM inference requires systems that understand token-level execution, manage rapidly growing context state, and continuously balance latency, throughput, and cost under highly dynamic workloads.
+
+The LLM Inference Framework addresses these challenges by transforming inference into a fully automated, reproducible lifecycle—from model onboarding and compilation to deployment, optimization, and observability. By integrating automated quantization and engine compilation, intelligent runtime selection, cold-start mitigation strategies, and LLM-specific observability metrics such as Time-to-First-Token and Inter-Token Latency, the platform ensures both high performance and operational simplicity.
+
+Equally important, the framework is designed with flexibility and future evolution in mind. Its runtime-agnostic architecture enables seamless adoption of emerging inference engines, hardware accelerators, and optimization techniques without requiring platform redesign. This ensures that teams can continuously leverage advancements in the rapidly evolving LLM ecosystem while maintaining consistent operational workflows.
+
+Ultimately, the goal of the platform is to make production-scale LLM deployment as seamless and reliable as traditional software deployment—allowing teams to focus on building intelligent applications rather than managing infrastructure complexity. By combining lifecycle automation, runtime optimization, and deep observability, the LLM Inference Framework provides a scalable foundation for delivering fast, cost-efficient, and production-ready LLM experiences.
+
+## Future Explorations
+
+While we have achieved significant milestones in latency and throughput, the landscape of GenAI is evolving rapidly. Our roadmap focuses on increasing flexibility, reducing costs, and enhancing reliability for enterprise-grade workloads. Here is what we are building next:
+
+- TPU Support: To diversify our hardware supply chain and further optimize cost-per-token, we are evaluating Google Cloud TPUs to bake it into our platform. By leveraging the JAX and PyTorch/XLA ecosystems, we aim to unlock the massive throughput potential of TPU v5e chips, particularly for our open-source Llama models. This will allow the hardware profiler to dynamically choose between NVIDIA GPUs and Google TPUs based on real-time availability and price-performance metrics.
+- Multi-LoRA Serving (Serverless Experience): Currently, deploying a fine-tuned model requires a dedicated GPU. We are building support for Multi-LoRA serving, which will allow us to serve hundreds of unique, fine-tuned adapters on top of a single frozen base model. This will drastically reduce costs for multi-tenant applications, enabling a "serverless" experience where specific fine-tunes are hot-swapped instantly per request.
+- Spot Instance Orchestration: To further optimize cloud costs, we are developing fault-tolerant mechanisms to run inference workloads on Spot Instances. By implementing aggressive checkpointing and seamless request draining, we aim to leverage cheaper, preemptible compute capacity without interrupting the user's streaming experience.
+- Semantic Caching Layer: We plan to move beyond standard Prefix Caching to implement Semantic Caching. By using a vector database to fetch responses for semantically similar queries (e.g., "How do I reset my password?" vs. "Password reset steps"), we can bypass the GPU entirely for repetitive queries, reducing latency to near-zero.
+- Context-Aware Autoscaling: Standard CPU/GPU utilization metrics are often insufficient signals for scaling LLMs. We are working on KV-cache pressure metrics for autoscaling. This ensures that we scale out before the memory fills up, preventing eviction-based slowdowns during traffic spikes.
+- Online Evaluation & Guardrails: We are integrating a lightweight "Trust Layer" into the proxy. This will allow for low-latency input/output filtering (Guardrails) and asynchronous "LLM-as-a-Judge" evaluation pipelines to monitor response quality in production, not just system health.
\ No newline at end of file
diff --git a/docs-src/blog/bharatmlstack-history/llm-inferencing-platform/llm-plat.png b/docs-src/blog/bharatmlstack-history/llm-inferencing-platform/llm-plat.png
new file mode 100644
index 00000000..1f0fa9f7
Binary files /dev/null and b/docs-src/blog/bharatmlstack-history/llm-inferencing-platform/llm-plat.png differ
diff --git a/docs-src/blog/bharatmlstack-history/post-one/index.md b/docs-src/blog/bharatmlstack-history/post-one/index.md
deleted file mode 100644
index aa933741..00000000
--- a/docs-src/blog/bharatmlstack-history/post-one/index.md
+++ /dev/null
@@ -1,240 +0,0 @@
----
-slug: post-one
-title: "Building Meesho’s ML Platform: From Chaos to Cutting-Edge (Part 1)"
-authors: [adarsha, aditya, bhawani, jigar]
-date: 2022-11-15
-tags: [online-feature-store, interaction-store, mlplatform, meesho]
----
-
-
-## The Genesis: How a Friday Night Roast Sparked Meesho’s ML Platform
-
-It all started in early 2022, over a casual Friday evening catch-up. Like many great origin stories, this one began with friendly banter between a group of backend engineers and data scientists. As the conversations unfolded, so did the roasting—until one remark hit a little too close to home:
-
-*"Why are we still crunching data for Monthly Active Users (MAU) when the next day it’s all about Daily Active Users (DAU)?"*
-
-The laughter died down, and the question lingered. When we regrouped on Monday—clear-headed and slightly reflective—we decided to dig into the numbers. What they discovered was quite revealing: a large portion of compute resources wasn’t being put to good use.
-Much of the system’s effort was spent supporting users who weren’t actively engaging, and even for new users, the experience wasn’t optimized to make a meaningful impact.
-
-At the same time, Meesho had just launched a company-wide initiative to reduce costs—and every team had to contribute. This realization sparked the journey that would eventually lead to the **Meesho ML Platform**, known today as **BharatMLStack**.
-
-
-
-Before the ML Platform, our recommendation and ranking pipelines followed a batch processing approach:
-- **Data Ingestion**: The Data Platform team executed ETL jobs to ingest raw user data—including user profiles, interaction logs, and product impressions—into designated S3 buckets.
-- **Layer 1**: Embedding Generation: On the Data Science side, Spark jobs pulled data from multiple S3 sources, cleaned and preprocessed it, and applied matrix factorization to generate user and item embeddings. The processed data and embeddings were then stored back in S3 in a structured format.
-- **Layer 2**: Candidate Generation (CG): In this stage, Spark jobs leveraged embeddings and historical interaction data to generate candidate recommendations for users. These candidate lists were subsequently written to S3.
-- **Layer 3**: Ranking and Merging – A final round of processing ranked the generated candidates using ML models, combined different candidate lists, and stored the final ranked recommendations in a caching system.
-- **Serving**: A microservice retrieved ranked recommendations from an in-memory data store via exposed APIs, delivering personalized listings across key surfaces such as "For You" and Category Landing Pages (CLP).
-
-This approach held up well—until Meesho started seeing a significant surge in traffic.
-
-## The Turning Point: From Batch to Real-Time
-
-At this time, the team was iterating on new **Ranker models**, and real-time inference seemed like the next logical step. But Rankers needed **real-time feature retrieval**, which meant an **online feature store** had to be built first.
-
-Exploring open-source options led to **cost vs. performance trade-offs**, but Meesho’s surging traffic meant that **latency and stability were non-negotiable**. After multiple debates and stakeholder discussions, a bold decision was made:
-
-*We would build our own feature store.*
-
-Meanwhile, efforts began to bring **Candidate Generators (CGs)** to real-time. The challenge? **Storing and retrieving user interactions quickly enough** to power real-time recommendations.
-
-As the team dove deeper, a new roadblock emerged:
-Our ML jobs were orchestrated using **Airflow DAGs**, giving data scientists flexibility in experimentation. But transitioning to real-time execution threatened this agility. Every change would now require backend engineering support, **slowing down iteration cycles**.
-
-That’s when the idea struck:
-We needed a **framework for real-time DAG execution**—one that preserved the same flexibility as Airflow but worked for **streaming data**.
-
-This moment shaped the **next phase of our journey**.
-
-## First Generation Design
-
-
-
-# Laying the Groundwork: The First-Gen ML Platform
-
-To solve these challenges, the team built three foundational components:
-
-
-### 1. IOP Framework: A Real-Time DAG Executor
-
-- **Reusable Nodes**: Each DAG node (e.g., an invocation to a CG service, a ranker, or a filter) had to be implemented only once. After that, it could be reused across any workflow by referencing it in config.
-- **Config-driven Dynamic Graphs**: Execution graphs were defined as adjacency lists stored in **ZooKeeper**, allowing teams to modify the sequence or structure of operations without touching application code.
-- **Plug-and-play CGs**: The Candidate Generator interface was preserved, so a single CG node could call any CG service by passing `cg_name` in the request. This drastically reduced the code surface area and improved maintainability.
-- **Production-Grade DAGs**: DAGs were designed to execute in **low-latency real-time environments**, with support for **parallel execution, retries, and branching**.
-
-[More about IOP DAG](https://www.meesho.io/blog/rebuilding-meeshos-ranking-platform)
-
-
-### 2. Online Feature Store - 0th Version
-
-- Used **Cassandra** and **Redis** for low-latency feature serving.
-- Maintained feature consistency using **Feature Groups** with TTL-based expiry.
-- A hybrid schema was used: feature keys stored in **ZooKeeper**, data stored in **compact arrays**.
-
-
-### 3. Interaction Store - 0th Version
-
-- Captured real-time user interactions like clicks, orders, and add-to-cart events.
-- Stored event data in **Redis ZSETs (sorted sets)** to enable fast lookups for recommendation engines.
-- Provided an API to fetch a user's **last _k_ interactions** or **interactions within a time window**.
-
-
-With these components in place, **real-time ML at Meesho became a reality**.
-
-This was just the beginning.
-
-## Building the Online Feature Store - 0th Version
-
-
-
-### Choosing the Right Tech Stack
-
-We spent considerable time evaluating various databases, caches, and communication protocols for our **online feature store**. After carefully weighing **cost, latency, throughput**, and **operational stability**, we settled on a combination of:
-
-- **Cassandra** and **Redis** for storage
-- **gRPC + Proto3** as our communication layer
-
-
-### Streamlining the Data Flow
-
-To keep things simple in the initial version:
-
-- **Feature engineering jobs** wrote raw outputs to an **S3 bucket**
-- A **daily feature push job**:
- - Read from S3
- - Grouped related features into **Feature Groups** (ensuring consistency)
- - Pushed them to **Kafka**
-
-For features requiring frequent updates:
-
-- **Ad-hoc jobs** computed features in higher frequency
-- These jobs pushed to both **Kafka** and **S3** (S3 preserved historical data for future model training)
-
-
-## The Challenges: Data Format and Storage
-
-One of the most critical design challenges was how to store feature data **efficiently and consistently**, especially in databases like **Cassandra** and **Redis**, which come with unique storage constraints.
-
-We had to solve for three key requirements:
-
-- ### Feature Consistency
- When a feature group contains features like `order_count_1h` and `click_count_1h`, both must reflect the **same time window**. Inconsistent updates would lead to **unreliable model predictions**.
-
-- ### TTL Granularity
- Each feature group required an **expiry timestamp**, so that **all features within it expired together**—preserving consistency during reads.
-
-- ### Extensibility Across Databases
- We anticipated that infra needs would evolve. To future-proof our system, the data format was designed to be **decoupled from DB-specific layouts**, enabling portability to systems like **ScyllaDB**, **DynamoDB**, **HBase**, or **BigTable**.
-
-
----
-
-## Overcoming Technical Constraints
-At the time, we were using Cassandra, which not only imposed a soft limit of 75 columns per row, but also exhibited significant performance degradation as the number of columns increased further, particularly in memory constrained machines. Wide rows caused high memory usage during reads, unpredictable latencies due to heavy deserialization overhead, and inefficiencies during compactions and repairs. This ruled out the naive "one column per feature" approach. We needed a format that was compact, minimized the number of columns, and remained efficient and portable across different storage systems.
-
-## The Solution: Schema Separation
-
-We introduced the concept of Feature Groups—logical groupings of features that must remain consistent with one another.
-To represent these groups efficiently, we adopted a layered storage approach:
-
-- **Feature Labels (Keys)** were stored in ZooKeeper, serving as the schema.
-- **Feature Values** were stored as a comma-separated string array in Cassandra or Redis.
-- **Expiry Timestamp and Schema Version** were appended using a semi-colon delimiter at the end of the string.
-
-Example:
-
-```bash
-feature_1_value,feature_2_value,feature_3_value;expiry_ts
-```
-
-This format allowed:
-- Consistent writes and reads at the group level
-- Easy parsing of feature values using the schema lookup from ZooKeeper
-- Efficient storage with minimal DB column usage
-- Support for per-group TTLs and schema evolution
-
-## Tracking Changes in Feature Groups
-Feature groups don’t stay static. As models evolve, features get added, renamed, or removed. But schema changes often go live before the data is ready—and stopping ingestion just to wait for everything to align isn't feasible.
-
-### Common Real-World Scenarios:
-- A new feature is added to the schema, but ingestion jobs still use the older schema version.
-- Ongoing writes don’t include the newly added feature, and stopping ingestion would break freshness for existing features.
-- During serving, models request a mix of old and new features, depending on rollout stages.
-
-## The Solution: Schema Versioning
-We solved this with versioned feature group schemas, which unlocked several capabilities:
-- ### Backward Compatibility
- Older ingestion jobs can continue writing using older schema versions. During reads, the system uses the schema version embedded in the value to interpret the data correctly.
-- ### Partial Availability Handling
- During inference, if some features in the request aren’t available (due to rollout delays or missing data), the system serves default values, ensuring the inference call doesn’t fail.
-- ### Safe Writes Without Pipeline Pauses
- With schema versioning, we no longer had to stop ingestion pipelines for schema updates. Writes using previous versions can continue safely, and downstream consumers evolve independently.
-This design gave us the flexibility to move fast without breaking things—preserving data quality, enabling experimentation, and ensuring reliability at scale.
-
-
-
-## Interaction Store - 0th Version
-
-
-
-To power real-time Candidate Generators (CGs), we needed fast access to user behavior signals—like what a user recently clicked, ordered, or added to their cart. These interactions form the basis for many real-time recommendations, such as **Similar Products**, **People Also Viewed**, or **Recently Ordered Again**.
-For the **0th version** of the Interaction Store, we focused on a design that was **simple, fast, and reliable** — optimized for high-throughput ingestion and low-latency lookups.
-
-## Event Ingestion
-We instrumented our backend services to emit key user interaction events to Kafka in real time. These included:
-- Click
-- Order
-- Add to Cart
-- Wishlist
-- Share
-
-Each event carried essential metadata:
-- userId — uniquely identifies the user
-- productId — the item being interacted with
-- timestamp — the moment the interaction occurred
-
-This decoupled the interaction logging from storage, allowing ingestion and consumption to scale independently.
-
-## Storage Design
-To store these events, we built Kafka consumers that processed the incoming streams and wrote the data into Redis, using sorted sets (ZSETs) as the primary data structure.
-
-### Why Redis?
-Redis gave us:
-- **Low-latency** reads and writes
-- **Time-ordered data** using ZSETs (via score = timestamp)
-- **Native TTL support**, if needed in later versions
-- **In-memory performance** —ideal for real-time CGs
-
-### Storage Structure
-Each user’s interactions were stored using a composite key format, uniquely identifying the user and interaction type. This structure allowed efficient organization and quick retrieval of recent activity for recommendation generation:
-
-```bash
-userId_eventType → ZSET[...(pid, ts)...]
-```
-
-Within each ZSET:
-
-- The **timestamp** served as the score, maintaining temporal order
-- The **productId** (optionally with metadata) was the **value**
-
-This allowed us to efficiently retrieve the interactions with HTTP-based API server with two query modes:
-- Fetch the **last k interactions** of a specific type for a given user with `ZREVRANGE(userId_eventType, count)`
-- Retrieve **all interactions within a time range** (e.g., last 24 hours) with `ZREVRANGEBYSCORE(userId_eventType, timeRange)`
-
-### Built-in Guardrails
-Since Redis was the sole store, we implemented High Availability (HA) to prevent data loss. To optimize memory usage, we also enforced size limits per event type—only storing the last k interactions per user, with older entries getting truncated.
-
-## Conclusion: Laying the Foundation for Real-Time ML
-
-In this first phase, we tackled the **fundamentals**—shifting from batch-based recommendations to a **real-time Recommendation** using ML platform that could keep up with Meesho’s growth.
-
-With the **IOP Framework**, **Online Feature Store**, and **Interaction Store**, we built the core infrastructure to support real-time personalization at scale. These wins have already unlocked:
-- ✅ Faster, more dynamic recommendations for millions of users.
-- ✅ Better infrastructure efficiency, reducing wasted compute power.
-- ✅ A flexible, modular system that allows for further experimentation.
-
-But this is just the beginning. While we've solved key challenges, **certain roadblocks remain** —from optimizing **cost-performance trade-offs** to **seamlessly evolving schemas**.
-
-
-This foundational work laid the path for a reliable and scalable **real-time feature serving layer**.
\ No newline at end of file
diff --git a/docs-src/blog/bharatmlstack-history/scaling-model-inference-and-embedding-search/bms.png b/docs-src/blog/bharatmlstack-history/scaling-model-inference-and-embedding-search/bms.png
new file mode 100644
index 00000000..b397fc88
Binary files /dev/null and b/docs-src/blog/bharatmlstack-history/scaling-model-inference-and-embedding-search/bms.png differ
diff --git a/docs-src/blog/bharatmlstack-history/scaling-model-inference-and-embedding-search/index.md b/docs-src/blog/bharatmlstack-history/scaling-model-inference-and-embedding-search/index.md
new file mode 100644
index 00000000..933b76bf
--- /dev/null
+++ b/docs-src/blog/bharatmlstack-history/scaling-model-inference-and-embedding-search/index.md
@@ -0,0 +1,102 @@
+---
+title: "Cracking the Code: Scaling Model Inference & Real-Time Embedding Search"
+description: "How Meesho scaled model inference with self-hosted Triton on GKE—slashing latency and costs by 65%—and built a real-time embedding search system on Qdrant to power personalized recommendations at scale."
+authors: [aditya, jaya, adarsha]
+slug: scaling-model-inference-and-embedding-search
+date: 2024-05-21
+tags: [model-inference, embedding-search, mlplatform, meesho, bharatmlstack]
+---
+
+
+By mid-2023, we had transformed our ML stack—building a real-time feature store, optimizing model retrieval, and fine-tuning ranking. But two critical gaps remained:
+
+- 🔹 Scaling model inference without hitting infrastructure roadblocks
+- 🔹 Moving embedding search from batch to real-time for candidate generation
+
+Here’s how we tackled these last-mile challenges, broke free from infrastructure constraints, and built a cost-efficient, high-performance system.
+
+## Breaking Free from the Scalability Ceiling
+
+### The Model Serving Bottleneck—A Wake-Up Call
+
+July 2023. With just months left for the Mega Blockbuster Sale (MBS), we noticed a serious issue—scaling our model-serving infrastructure was taking 10–15 minutes. In real-time ML, that’s an eternity.
+In one of our war rooms, we ran a quick experiment:
+
+- 🚀 We deployed an XGBoost model on a self-hosted Triton Inference Server running on a 16-core machine.
+- 🚀 Fired requests and compared the outputs with our existing cloud-hosted setup.
+- 🚀 The results matched—perfectly.
+
+That moment changed everything. We prepped a backup Triton setup on EKS, just in case our cloud provider couldn't allocate enough compute resources in time. Luckily, they did—but the seed was planted.
+Then in October, just two weeks before MBS, we got an alarming response from our infrastructure team:
+ "Node availability may be an issue."
+With no time to waste, we moved 30% of real-time ML traffic to our self-hosted Triton cluster. The results?
+
+- ✅ p99 latency dropped from 90–100ms to 30–40ms
+- ✅ Triton handled significantly higher throughput on fewer resources
+- ✅ No model changes were needed
+
+MBS ran without a hitch, proving that self-hosted inference was the way forward.
+
+### Scaling Triton on GKE
+
+This left us with two choices:
+
+- 1️⃣ Port models to a managed cloud inference service, investing time in learning a new deployment stack
+- 2️⃣ Scale our existing Triton setup on GKE, optimizing for cost and performance
+
+We went with Option 2—and it slashed inference costs to 35% of what we previously paid, while giving us full control over scaling and optimizations.
+
+### Fixing the Cold Start Problem
+
+As we onboarded more deep learning (DL) models, we hit a new bottleneck, new inference pods took 7–9 minutes to spin up.
+
+After profiling, we found the culprits:
+
+- Triton’s base image—a massive 5GB
+- Model binaries—often 1GB+
+- Startup delay—mostly due to downloading and initializing these assets
+
+To fix this, we built a lightweight Triton image, stripping unused components and shrinking the size to 900MB. This cut cold start times drastically, making auto-scaling faster and smoother.
+
+## Embedding Search: The Last Piece of the Puzzle
+
+By mid-2023, most of our ML stack had gone real-time—except for Candidate Generation (CG), which still ran in batch mode. To truly power real-time recommendations, we needed an online embedding search system.
+
+### Choosing the Right Vector Database
+
+We benchmarked three production-ready vector DBs across key parameters:
+
+- Milvus
+- Qdrant
+- Weaviate
+
+After extensive POCs, Qdrant stood out for its:
+
+- ✅ Blazing-fast search latency on high-dimensional vectors
+- ✅ Efficient memory usage, crucial for in-memory workloads
+- ✅ Support for upserts and soft deletes, vital for Ads use cases
+- ✅ gRPC + REST APIs, making integration seamless
+- ✅ Powerful filtering, allowing fine-tuned retrieval (e.g., filtering Ads by category, active status, etc.)
+
+At its core, Qdrant uses HNSW indexing, delivering both high recall and low-latency nearest-neighbor search—a perfect fit for our needs.
+
+### Embedding Freshness & Real-Time Updates
+
+To ensure embeddings stayed up to date, we built a dual ingestion pipeline:
+
+- 📌 Daily Refresh: A bulk pipeline updated embeddings overnight
+- 📌 Real-Time Updates: Ads events triggered immediate upserts/deletes
+
+This setup powered real-time "Similar Products" recommendations on the product page and became the foundation for Ads Candidate Generation, ensuring the right ads surfaced in milliseconds.
+
+
+
+## Final Takeaways: Scaling Smartly for Real-Time ML
+
+- 🚀 Self-hosted inference on Triton gave us lower cost, faster scaling, and better performance than managed services
+- 🚀 Building a custom Triton image reduced cold starts, improving responsiveness
+- 🚀 Qdrant-based embedding search enabled real-time personalization at scale
+- 🚀 Real-time updates for embeddings unlocked dynamic, up-to-date recommendations
+
+By early 2024, Meesho’s ML stack had evolved into a fully real-time, scalable, and cost-efficient system, setting the foundation for even bigger leaps ahead.
+
diff --git a/docs-src/blog/bharatmlstack-history/scaling-model-inference-and-embedding-search/vss.png b/docs-src/blog/bharatmlstack-history/scaling-model-inference-and-embedding-search/vss.png
new file mode 100644
index 00000000..c6b18475
Binary files /dev/null and b/docs-src/blog/bharatmlstack-history/scaling-model-inference-and-embedding-search/vss.png differ
diff --git a/docs-src/docs/inferflow/_category_.json b/docs-src/docs/inferflow/_category_.json
new file mode 100644
index 00000000..384c93bd
--- /dev/null
+++ b/docs-src/docs/inferflow/_category_.json
@@ -0,0 +1,8 @@
+{
+ "label": "Inferflow",
+ "position": 2,
+ "link": {
+ "type": "generated-index",
+ "description": "Inferflow is a graph-driven feature retrieval and model inference orchestration engine. It dynamically resolves entity relationships via configurable DAGs, retrieves features from the Online Feature Store, and orchestrates model scoring — all without custom code."
+ }
+}
diff --git a/docs-src/docs/inferflow/v1.0.0/_category_.json b/docs-src/docs/inferflow/v1.0.0/_category_.json
new file mode 100644
index 00000000..3c72a212
--- /dev/null
+++ b/docs-src/docs/inferflow/v1.0.0/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "v1.0.0",
+ "position": 1
+}
diff --git a/docs-src/docs/inferflow/v1.0.0/architecture.md b/docs-src/docs/inferflow/v1.0.0/architecture.md
new file mode 100644
index 00000000..789e9a4d
--- /dev/null
+++ b/docs-src/docs/inferflow/v1.0.0/architecture.md
@@ -0,0 +1,267 @@
+---
+title: Architecture
+sidebar_position: 1
+---
+
+# BharatMLStack - Inferflow
+
+Inferflow is part of **BharatMLStack**, a graph-driven feature retrieval and model inference orchestration engine built in **Go**. It eliminates the need for custom feature retrieval code by using configurable DAG topologies to dynamically resolve entity relationships, fetch features from the Online Feature Store, and orchestrate model scoring — all driven by configuration stored in **etcd**.
+
+---
+
+## Overview
+
+In a typical ML serving pipeline, every new model requires bespoke code to:
+- Fetch features from multiple entities (user, product, user x category, etc.)
+- Infer intermediate entity relationships (e.g., extract category from product to fetch user x category data)
+- Orchestrate one or more model inference calls
+- Handle I/O, batching, and error propagation
+
+Inferflow abstracts all of this behind a **config-driven DAG executor**. Given a `model_config_id` and context entities (e.g., `userId`, `productIds`), it:
+
+1. Loads a pre-defined feature retrieval and inference graph from etcd
+2. Executes the graph to resolve entity relationships dynamically
+3. Retrieves features from the Online Feature Store (OnFS) in parallel
+4. Calls model serving endpoints (Predator) and compute services (Numerix)
+5. Returns scored results as a structured response
+
+---
+
+## High-Level Architecture
+
+
+
+The diagram shows the internal DAG structure of Inferflow's topology executor. gRPC APIs (Pair, Point, Slate) feed into the DAG, where **Feature Init** bootstraps the ComponentMatrix. Feature components (FS User, FS Product, FS Region, FS User Cat, FS Region Scat) fetch features from **OnFS** in parallel and populate columns in the shared **2D Result Matrix**. Model components (Model A, Model B) call **Predator** for inference, and compute components call **Numerix** for operations like reranking. The entire DAG topology is driven by config loaded from **etcd**.
+
+---
+
+## Core Components
+
+### 1. gRPC Server
+
+Inferflow exposes its APIs via a gRPC server, with HTTP health endpoints multiplexed on the same port using **cmux**. The server provides:
+
+- **Inferflow API** — `RetrieveModelScore`: entity-based feature retrieval and scoring
+- **Predict API** — `InferPointWise`, `InferPairWise`, `InferSlateWise`: structured inference with targets, pairs, and slates
+
+### 2. DAG Topology Executor
+
+The heart of Inferflow. Each model configuration defines a `component_dependency` map that describes a Directed Acyclic Graph (DAG) of components.
+
+**Execution model:**
+- Uses **Kahn's algorithm** for topological ordering
+- Components at the same level run **concurrently** in goroutines
+- All components share a mutable `ComponentMatrix` (rows = entity IDs, columns = features/scores)
+- DAG topologies are **cached** using Murmur3 hashing with Ristretto cache
+
+**Validation:**
+- Cycle detection via in-degree analysis
+- Component existence verification against the `ComponentProvider`
+
+### 3. Component Types
+
+Inferflow defines four types of DAG components:
+
+| Component | Role | External Dependency |
+|-----------|------|---------------------|
+| **FeatureInitComponent** | Root node — initializes the `ComponentMatrix` with entity IDs and schema | None |
+| **FeatureComponent** | Fetches features from the Online Feature Store for a specific entity type | OnFS (gRPC) |
+| **PredatorComponent** | Calls model serving endpoints for inference scoring | Predator / Helix (gRPC) |
+| **NumerixComponent** | Calls compute engine for operations like reranking | Numerix (gRPC) |
+
+### 4. ComponentMatrix — The 2D Result Matrix
+
+The ComponentMatrix is a shared, mutable 2D data structure that flows through the entire DAG. Every component reads from and writes to this matrix, progressively building a complete feature + score row for each entity.
+
+
+
+#### How the matrix evolves through the DAG
+
+The diagram above illustrates the three execution phases and how the 2D matrix grows at each stage:
+
+**Phase 1 — Feature Retrieval**
+
+The **init** node creates an empty matrix with one row per target entity ID. Feature components then execute — first the top-level entities (entity A, entity B) fetch their features from OnFS and populate their columns (shown as colored blocks). Derived entities (entity C, D, E) resolve their keys from the already-populated columns and add more feature columns. At this point the matrix contains all feature data, with each color representing features from a different entity.
+
+The right side of the diagram shows the matrix being **decomposed** — feature columns from different entities are separated into per-model input groups, selecting only the features each model needs.
+
+**Phase 2 — Model Invocation**
+
+Model X and Model Y each receive their decomposed feature slices, call **Predator** for inference, and write score columns back into the matrix (shown as new colored columns appended to the right). Multiple models can run in parallel if they don't depend on each other's outputs.
+
+The scores are then decomposed again to prepare inputs for the compute stage.
+
+**Phase 3 — Numerix Compute**
+
+The **Score Comb** node takes score columns from both models, calls **Numerix** for a final compute operation (e.g., score combination, reranking), and writes the final score column (shown in dark red) into the matrix. The result is a complete row per entity with all features and all scores.
+
+#### Matrix structure
+
+| Property | Description |
+|----------|-------------|
+| **Rows** | One per target entity ID (e.g., each product being scored) |
+| **String columns** | Human-readable values used in responses |
+| **Byte columns** | Binary-encoded feature values used for model inputs |
+| **Column naming** | `entity_label:feature_group:feature_name` |
+
+Each component only reads the columns it needs and writes to its own columns, enabling safe concurrent execution across independent branches of the DAG.
+
+For slate-based APIs, a companion `SlateData` structure holds per-slate matrices and scores, with `slate_target_indices` mapping slates to rows in the main matrix.
+
+### 5. Configuration Management (etcd)
+
+Model configurations are stored in etcd and hot-reloaded via watchers:
+
+- **Config paths**: `/config/inferflow/services/`, `/model-config`
+- **Watch mechanism**: etcd watchers trigger `ReloadModelConfigMapAndRegisterComponents` on any change
+- **On reload**: Updates `ConfigMap`, re-initializes feature schemas, and re-registers DAG components
+
+This means new models or configuration changes go live **without redeployment**.
+
+### 6. External Integrations
+
+#### Online Feature Store (OnFS)
+- gRPC client calling `FeatureService.RetrieveFeatures`
+- Batched retrieval with configurable batch size and deadline
+- Auth via `CALLER_ID` and `CALLER_TOKEN` metadata
+
+#### Predator (Model Serving)
+- Uses `go-sdk` for model inference
+- Supports **percentage-based traffic routing** across multiple model endpoints
+- Configurable calibration and batch sizing
+
+#### Numerix (Compute Engine)
+- Uses `go-sdk` Numerix client
+- RPC: `NumerixService.Compute` with entity score data
+- Used for compute operations like reranking
+
+#### Kafka (Inference Logging)
+- Async inference log publishing using `segmentio/kafka-go`
+- Supports **Proto**, **Arrow**, and **Parquet** serialization formats
+- Configurable sampling via `LoggingPerc` and user-based daily sampling
+
+---
+
+## Request Flow
+
+```
+1. Client sends gRPC request with model_config_id + entity IDs
+ │
+2. Load ModelConfig from etcd-backed ConfigMap
+ │
+3. Adapt proto request → ComponentRequest
+ (build ComponentMatrix with entity schema)
+ │
+4. Resolve DAG topology from component_dependency config
+ │
+5. Execute DAG (Kahn's algorithm, concurrent):
+ │
+ ├─ FeatureInitComponent: populate matrix with entity IDs + schema
+ │
+ ├─ FeatureComponents (parallel): fetch features from OnFS → fill matrix columns
+ │
+ ├─ PredatorComponent: build feature payloads from matrix → call model → write scores
+ │
+ └─ NumerixComponent: read scores from matrix → call compute → write final scores
+ │
+6. Build response from matrix columns per ResponseConfig
+ │
+7. (Optional) Async Kafka logging of inference features and scores
+ │
+8. Return gRPC response to client
+```
+
+---
+
+## Observability
+
+### Metrics (StatsD / Telegraf)
+
+| Metric | Description |
+|--------|-------------|
+| `inferflow.retrievemodelscore.request.total` | Total RetrieveModelScore requests |
+| `inferflow.retrievemodelscore.latency` | End-to-end latency |
+| `inferflow.retrievemodelscore.batch.size` | Batch size per request |
+| `predict.infer.request.total` | Total Predict API requests |
+| `predict.infer.latency` | Predict API latency |
+| `inferflow.component.execution.total` | Per-component execution count |
+| `inferflow.component.execution.latency` | Per-component latency |
+| `inferflow.component.execution.error` | Component-level errors |
+| `inferflow.component.feature.count` | Feature count per component |
+| `inferflow.external.api.request.total` | External API call count |
+| `inferflow.external.api.latency` | External API latency |
+| `inferflow.component.inmemorycache.request.total` | Cache hit/miss total |
+| `inferflow.component.inmemorycache.miss` | Cache misses |
+| `inferflow.logging.kafka_sent` | Kafka log messages sent |
+
+### Logging
+- Structured JSON logging via **zerolog**
+- Configurable log levels
+
+---
+
+## Deployment
+
+### Docker
+
+Inferflow ships as a multi-stage Docker image:
+
+- **Builder**: Go 1.19 Alpine with optional Kafka support (librdkafka)
+- **Runtime**: Debian 10 slim
+- **Build command**: `go build -tags musl -ldflags "-extldflags -static" -o server cmd/${module}/main.go`
+
+### Supported Environments
+- Kubernetes (K8s)
+- Google Kubernetes Engine (GKE)
+- Amazon EKS
+
+### Configuration
+All configuration is driven via environment variables (loaded by Viper) and etcd. No config files are required at deployment time.
+
+---
+
+## Target Users
+
+| User | Role |
+|------|------|
+| Data Scientists | Define model configs and feature retrieval graphs via config — no code needed |
+| ML Engineers | Onboard new models by updating etcd config; manage DAG topologies |
+| Backend Developers | Integrate via gRPC SDKs for real-time scoring in application services |
+| Platform Engineers | Deploy, scale, and monitor Inferflow clusters |
+
+---
+
+## Benefits
+
+- **No-code feature retrieval** — new models need only a config change, not custom code
+- **Feature consistency** — same graph-driven retrieval ensures identical features across experiments
+- **Faster iteration** — experiment with new models in minutes, not days
+- **Concurrent execution** — DAG components run in parallel for minimal latency
+- **Hot reloading** — model config changes via etcd go live without redeployment
+- **Multi-API support** — PointWise, PairWise, and SlateWise inference patterns out of the box
+- **Production-grade** — built in Go with gRPC, designed for millions of QPS
+
+---
+
+## Contributing
+
+We welcome contributions from the community! Please see our [Contributing Guide](https://github.com/Meesho/BharatMLStack/blob/main/CONTRIBUTING.md) for details on how to get started.
+
+## Community & Support
+
+- **Discord**: Join our [community chat](https://discord.gg/XkT7XsV2AU)
+- **Issues**: Report bugs and request features on [GitHub Issues](https://github.com/Meesho/BharatMLStack/issues)
+- **Email**: Contact us at [ml-oss@meesho.com](mailto:ml-oss@meesho.com)
+
+## License
+
+BharatMLStack is open-source software licensed under the [BharatMLStack Business Source License 1.1](https://github.com/Meesho/BharatMLStack/blob/main/LICENSE.md).
+
+---
+
+
+ Built with ❤️ for the ML community from Meesho
+
+
+ If you find this useful, ⭐️ the repo — your support means the world to us!
+
diff --git a/docs-src/docs/inferflow/v1.0.0/configuration.md b/docs-src/docs/inferflow/v1.0.0/configuration.md
new file mode 100644
index 00000000..35b9b1bd
--- /dev/null
+++ b/docs-src/docs/inferflow/v1.0.0/configuration.md
@@ -0,0 +1,366 @@
+---
+title: Configuration Guide
+sidebar_position: 3
+---
+
+# Inferflow - Configuration Guide
+
+Inferflow is fully config-driven. All model onboarding, feature retrieval logic, DAG topology, and inference behavior are controlled through configuration stored in **etcd** — with zero code changes required.
+
+---
+
+## Configuration Overview
+
+Inferflow configuration is organized into two layers:
+
+1. **Static config** — Environment variables loaded at startup (via Viper)
+2. **Dynamic config** — Model configurations stored in etcd, hot-reloaded on change
+
+---
+
+## Static Configuration (Environment Variables)
+
+These are set at deployment time and require a restart to change.
+
+### Server
+
+| Variable | Description | Example |
+|----------|-------------|---------|
+| `APP_PORT` | gRPC/HTTP server port | `50051` |
+| `APP_ENV` | Environment name | `production` |
+
+### etcd
+
+| Variable | Description | Example |
+|----------|-------------|---------|
+| `ETCD_ENDPOINTS` | Comma-separated etcd endpoints | `etcd-0:2379,etcd-1:2379` |
+| `ETCD_DIAL_TIMEOUT` | Connection timeout | `5s` |
+
+### Online Feature Store (OnFS)
+
+| Variable | Description | Example |
+|----------|-------------|---------|
+| `externalServiceOnFs_host` | OnFS gRPC host | `onfs-api:50051` |
+| `externalServiceOnFs_callerId` | Caller ID for auth | `inferflow` |
+| `externalServiceOnFs_callerToken` | Caller token for auth | `` |
+| `externalServiceOnFs_batchSize` | Batch size for feature retrieval | `100` |
+| `externalServiceOnFs_deadline` | Request deadline | `200ms` |
+
+### Predator (Model Serving)
+
+| Variable | Description | Example |
+|----------|-------------|---------|
+| `externalServicePredator_defaultDeadline` | Default inference deadline | `100ms` |
+
+### Numerix (Compute Engine)
+
+| Variable | Description | Example |
+|----------|-------------|---------|
+| `numerixClientV1_host` | Numerix gRPC host | `numerix:50052` |
+| `numerixClientV1_deadline` | Request deadline | `100ms` |
+
+### Kafka (Inference Logging)
+
+| Variable | Description | Example |
+|----------|-------------|---------|
+| `KafkaBootstrapServers` | Kafka broker addresses | `kafka-0:9092,kafka-1:9092` |
+| `KafkaLoggingTopic` | Topic for inference logs | `inferflow-logs` |
+
+### Metrics (StatsD / Telegraf)
+
+| Variable | Description | Example |
+|----------|-------------|---------|
+| `TELEGRAF_HOST` | StatsD host | `telegraf` |
+| `TELEGRAF_PORT` | StatsD port | `8125` |
+
+### In-Memory Cache
+
+| Variable | Description | Example |
+|----------|-------------|---------|
+| `CACHE_SIZE_MB` | Cache size in MB | `512` |
+| `CACHE_TYPE` | Cache implementation | `freecache` |
+
+---
+
+## Dynamic Configuration (etcd Model Config)
+
+Model configurations are stored in etcd and hot-reloaded. Each model is identified by a `model_config_id`.
+
+### Config Structure
+
+```json
+{
+ "model_config_id_example": {
+ "dag_execution_config": {
+ "component_dependency": {
+ "feature_initializer": ["fs_user", "fs_product"],
+ "fs_user": ["ranker_model"],
+ "fs_product": ["ranker_model"],
+ "ranker_model": []
+ }
+ },
+ "component_config": {
+ "feature_component_config": {
+ "fs_user": { ... },
+ "fs_product": { ... }
+ },
+ "predator_component_config": {
+ "ranker_model": { ... }
+ },
+ "numerix_component_config": {},
+ "cache_enabled": true,
+ "cache_version": "v1",
+ "cache_ttl": 300,
+ "error_logging_percent": 10
+ },
+ "response_config": {
+ "features": ["ranker_model:score"],
+ "model_schema_perc": 100,
+ "logging_perc": 5,
+ "log_features": ["fs_user:profile:age", "ranker_model:score"],
+ "log_batch_size": 100
+ }
+ }
+}
+```
+
+---
+
+### DAG Execution Config
+
+Defines the component dependency graph.
+
+```json
+{
+ "component_dependency": {
+ "": ["", ""],
+ "": [""],
+ "": [""],
+ "": []
+ }
+}
+```
+
+**Rules:**
+- The graph must be a valid DAG (no cycles)
+- Components with no parents (zero in-degree) execute first
+- Components with empty dependency arrays `[]` are leaf nodes
+- All component names must match registered components in the `ComponentConfig`
+
+---
+
+### Feature Component Config
+
+Configures how features are fetched from the Online Feature Store.
+
+```json
+{
+ "fs_user": {
+ "fs_keys": {
+ "schema": ["user_id"],
+ "col": "context:user:user_id"
+ },
+ "fs_request": {
+ "entity_label": "user",
+ "feature_groups": [
+ {
+ "label": "demographics",
+ "feature_labels": ["age", "location", "income_bracket"]
+ },
+ {
+ "label": "behavior",
+ "feature_labels": ["click_rate", "purchase_freq"]
+ }
+ ]
+ },
+ "fs_flatten_resp_keys": ["user_id"],
+ "col_name_prefix": "user",
+ "comp_cache_enabled": true,
+ "comp_cache_ttl": 600,
+ "composite_id": false
+ }
+}
+```
+
+| Field | Description |
+|-------|-------------|
+| `fs_keys` | How to extract lookup keys from the matrix. `schema` defines key column names; `col` references a matrix column |
+| `fs_request` | OnFS query: entity label + feature groups with specific features |
+| `fs_flatten_resp_keys` | Keys to flatten in response mapping |
+| `col_name_prefix` | Prefix for matrix column names (e.g., `user:demographics:age`) |
+| `comp_cache_enabled` | Enable in-memory caching for this component |
+| `comp_cache_ttl` | Cache TTL in seconds |
+| `composite_id` | Whether entity keys are composite |
+
+---
+
+### Predator Component Config
+
+Configures model inference endpoints.
+
+```json
+{
+ "ranker_model": {
+ "model_name": "product_ranker_v3",
+ "model_endpoint": "predator-ranker:8080",
+ "model_end_points": {
+ "predator-ranker-v3:8080": 80,
+ "predator-ranker-v4:8080": 20
+ },
+ "deadline": 100,
+ "batch_size": 50,
+ "calibration": {
+ "enabled": false
+ },
+ "inputs": {
+ "feature_map": {
+ "user:demographics:age": "INT32",
+ "user:behavior:click_rate": "FP32",
+ "product:attributes:category_id": "INT32"
+ }
+ },
+ "outputs": {
+ "score_columns": ["score", "confidence"]
+ },
+ "slate_component": false
+ }
+}
+```
+
+| Field | Description |
+|-------|-------------|
+| `model_name` | Model identifier on the serving platform |
+| `model_endpoint` | Primary model serving endpoint |
+| `model_end_points` | Multiple endpoints with percentage-based traffic routing |
+| `deadline` | Inference timeout in milliseconds |
+| `batch_size` | Max items per inference batch |
+| `calibration` | Score calibration settings |
+| `inputs.feature_map` | Map of matrix column → data type for model input |
+| `outputs.score_columns` | Column names for model output scores |
+| `slate_component` | If true, runs per-slate inference |
+
+---
+
+### Numerix Component Config
+
+Configures compute operations (e.g., reranking).
+
+```json
+{
+ "reranker": {
+ "score_column": "final_score",
+ "data_type": "FP32",
+ "score_mapping": {
+ "ranker_model:score": "FP32",
+ "user:behavior:click_rate": "FP32"
+ },
+ "compute_id": "diversity_rerank_v1",
+ "slate_component": false
+ }
+}
+```
+
+| Field | Description |
+|-------|-------------|
+| `score_column` | Output column name for the computed score |
+| `data_type` | Output data type |
+| `score_mapping` | Map of matrix columns to include as compute inputs |
+| `compute_id` | Identifies the compute operation on Numerix |
+| `slate_component` | If true, runs per-slate compute |
+
+---
+
+### Response Config
+
+Controls what data is returned to the client and what is logged.
+
+```json
+{
+ "features": ["ranker_model:score", "reranker:final_score"],
+ "model_schema_perc": 100,
+ "logging_perc": 5,
+ "log_features": [
+ "user:demographics:age",
+ "ranker_model:score",
+ "reranker:final_score"
+ ],
+ "log_batch_size": 100
+}
+```
+
+| Field | Description |
+|-------|-------------|
+| `features` | Matrix columns to include in the gRPC response |
+| `model_schema_perc` | Percentage of requests that include full schema in response |
+| `logging_perc` | Percentage of requests to send to Kafka for logging |
+| `log_features` | Specific features to include in log messages |
+| `log_batch_size` | Batch size for grouped log messages |
+
+---
+
+### Service-Level Config
+
+Global settings that apply across all models.
+
+```json
+{
+ "v2_logging_type": "proto",
+ "compression_enabled": false
+}
+```
+
+| Field | Values | Description |
+|-------|--------|-------------|
+| `v2_logging_type` | `proto`, `arrow`, `parquet` | Serialization format for Kafka inference logs |
+| `compression_enabled` | `true`, `false` | Enable compression for log messages |
+
+---
+
+## Example: Onboarding a New Model
+
+To onboard a new ranking model, update the etcd config:
+
+**Step 1:** Define the feature retrieval graph
+
+```json
+"component_dependency": {
+ "feature_initializer": ["fs_user", "fs_product", "fs_user_x_category"],
+ "fs_product": ["fs_user_x_category"],
+ "fs_user": ["new_ranker"],
+ "fs_user_x_category": ["new_ranker"],
+ "new_ranker": []
+}
+```
+
+Here `fs_user_x_category` depends on `fs_product` because it needs the category ID extracted from the product entity to resolve the user x category key.
+
+**Step 2:** Configure each component (feature groups, model endpoints, etc.)
+
+**Step 3:** Push the config to etcd — Inferflow picks it up automatically via watchers.
+
+No code changes. No redeployment. The new model is live.
+
+---
+
+## Contributing
+
+We welcome contributions from the community! Please see our [Contributing Guide](https://github.com/Meesho/BharatMLStack/blob/main/CONTRIBUTING.md) for details on how to get started.
+
+## Community & Support
+
+- **Discord**: Join our [community chat](https://discord.gg/XkT7XsV2AU)
+- **Issues**: Report bugs and request features on [GitHub Issues](https://github.com/Meesho/BharatMLStack/issues)
+- **Email**: Contact us at [ml-oss@meesho.com](mailto:ml-oss@meesho.com)
+
+## License
+
+BharatMLStack is open-source software licensed under the [BharatMLStack Business Source License 1.1](https://github.com/Meesho/BharatMLStack/blob/main/LICENSE.md).
+
+---
+
+
+ Built with ❤️ for the ML community from Meesho
+
+
+ If you find this useful, ⭐️ the repo — your support means the world to us!
+
diff --git a/docs-src/docs/inferflow/v1.0.0/functionalities.md b/docs-src/docs/inferflow/v1.0.0/functionalities.md
new file mode 100644
index 00000000..cb944b1b
--- /dev/null
+++ b/docs-src/docs/inferflow/v1.0.0/functionalities.md
@@ -0,0 +1,309 @@
+---
+title: Key Functionalities
+sidebar_position: 2
+---
+
+# Inferflow - Key Functionalities
+
+## Overview
+
+Inferflow is a high-performance, config-driven ML inference orchestration engine built in **Go**. It provides **no-code feature retrieval**, **DAG-based execution**, and **multi-pattern model inference** — enabling ML teams to onboard new models through configuration changes alone.
+
+---
+
+## Core Capabilities
+
+### Graph-Driven Feature Retrieval
+
+Inferflow's defining feature is its ability to resolve entity relationships and retrieve features through configurable DAG topologies — no custom code required.
+
+**How it works:**
+
+1. A `model_config_id` maps to a pre-defined DAG of components
+2. Context entity IDs (e.g., `userId`, `productIds`) are provided at request time
+3. The DAG resolves intermediate entity relationships (e.g., extracting `category` from `product` to fetch `user x category` features)
+4. Features are fetched in parallel from the Online Feature Store
+5. A 2D feature matrix is assembled and passed to model scoring
+
+**Impact:**
+- New models require only a config update — no code changes
+- Feature consistency is guaranteed across experiments
+- Iteration cycles drop from days to minutes
+
+### DAG Topology Executor
+
+The execution engine uses **Kahn's algorithm** for topological ordering with **concurrent goroutine execution** at each level:
+
+```
+component_dependency: {
+ "feature_initializer": ["fs_user", "fs_product"],
+ "fs_user": ["ranker"],
+ "fs_product": ["ranker"],
+ "ranker": ["reranker"],
+ "reranker": []
+}
+```
+
+This config defines:
+- `feature_initializer` runs first (zero in-degree)
+- `fs_user` and `fs_product` run **in parallel** after init
+- `ranker` runs after both feature components complete
+- `reranker` runs after the ranker
+
+**Key properties:**
+- Cycle detection via in-degree analysis
+- DAG topologies cached using Murmur3 hashing (Ristretto cache)
+- Components are registered and resolved via a `ComponentProvider`
+
+---
+
+## Multi-Pattern Inference APIs
+
+Inferflow supports three inference patterns via the **Predict API**, each designed for different ML use cases:
+
+### PointWise Inference
+
+Score each target independently against context features.
+
+```protobuf
+rpc InferPointWise(PredictRequest) returns (PredictResponse);
+```
+
+**Use cases:** Click-through rate prediction, fraud scoring, relevance ranking
+
+**Input:** Context features + list of targets (e.g., products)
+**Output:** Per-target scores
+
+### PairWise Inference
+
+Score pairs of targets relative to each other.
+
+```protobuf
+rpc InferPairWise(PredictRequest) returns (PredictResponse);
+```
+
+**Use cases:** Preference learning, comparison-based ranking
+
+**Input:** Context features + targets + pair indices (first/second)
+**Output:** Per-pair scores + optional per-target scores
+
+### SlateWise Inference
+
+Score groups (slates) of targets together, capturing inter-item effects.
+
+```protobuf
+rpc InferSlateWise(PredictRequest) returns (PredictResponse);
+```
+
+**Use cases:** Whole-page optimization, slate-level reranking, diversity-aware scoring
+
+**Input:** Context features + targets + slate definitions (target indices per slate)
+**Output:** Per-slate scores + optional per-target scores
+
+---
+
+## Entity & Legacy API
+
+### RetrieveModelScore
+
+The original Inferflow API for entity-based feature retrieval and scoring:
+
+```protobuf
+service Inferflow {
+ rpc RetrieveModelScore(InferflowRequestProto) returns (InferflowResponseProto);
+}
+```
+
+**Request structure:**
+
+| Field | Description |
+|-------|-------------|
+| `entities` | List of entity types with their IDs and optional inline features |
+| `model_config_id` | Identifies the model configuration (DAG, components, response format) |
+| `tracking_id` | Request-level tracing identifier |
+
+**Entity structure:**
+- `entity`: Entity type label (e.g., `"user"`, `"product"`)
+- `ids`: List of entity IDs
+- `features`: Optional inline features (name + per-ID values)
+
+---
+
+## Component Types
+
+### FeatureInitComponent
+
+**Role:** Root DAG node — initializes the shared `ComponentMatrix`.
+
+- Sets up rows from entity IDs
+- Populates schema columns (string + byte) for all downstream components
+- For slate APIs: initializes `SlateData` with `slate_target_indices`
+
+### FeatureComponent
+
+**Role:** Fetches features from the Online Feature Store (OnFS) for a specific entity type.
+
+- Reads `FSKeys` from config to extract lookup keys from the matrix
+- Batches unique entities and calls OnFS via gRPC
+- Optional **in-memory caching** keyed by `model_id:version:component:entity`
+- Writes binary feature values into matrix byte columns
+
+**Column naming convention:** `entity_label:feature_group:feature_name`
+
+### PredatorComponent
+
+**Role:** Calls model serving endpoints for inference.
+
+- Builds feature payloads from matrix columns with type conversion
+- Supports **percentage-based traffic routing** across multiple model endpoints
+- Handles **slate-level inference**: per-slate matrix → separate inference → scores to `SlateData`
+- Configurable **calibration** and **batch sizing**
+
+### NumerixComponent
+
+**Role:** Calls the Numerix compute engine for operations like reranking.
+
+- Uses `ScoreMapping` config to map matrix columns to compute inputs
+- Writes a single score column back to the matrix
+- Supports slate mode for per-slate compute operations
+
+---
+
+## Feature Retrieval Pipeline
+
+### Key Resolution
+
+Feature components use `FSKeys` configuration to dynamically resolve entity keys:
+
+```json
+{
+ "FSKeys": {
+ "schema": ["user_id"],
+ "col": "user:profile:user_id"
+ }
+}
+```
+
+The component reads key values from the existing matrix columns, enabling **chained entity resolution** — e.g., fetch product entity first, extract category, then fetch user x category features.
+
+### Batched Retrieval
+
+- Features are fetched via `FeatureService.RetrieveFeatures` gRPC call
+- Requests are batched by unique entity keys
+- Configurable batch size and deadline per component
+- Auth via `CALLER_ID` and `CALLER_TOKEN` metadata
+
+### In-Memory Caching
+
+Optional per-component caching reduces OnFS load:
+
+- Cache key: `model_id:cache_version:component_name:entity_key`
+- Configurable TTL per component
+- Zero-GC-overhead cache implementation available
+- Cache hit/miss metrics tracked via StatsD
+
+---
+
+## Data Types
+
+Inferflow supports comprehensive ML data types for feature encoding and model input/output:
+
+| Data Type | Variants | Usage |
+|-----------|----------|-------|
+| **Integers** | int8, int16, int32, int64 | Categorical encodings, counts, IDs |
+| **Floats** | float8 (e4m3, e5m2), float16, float32, float64 | Continuous features, embeddings, scores |
+| **Strings** | Variable length | Categories, metadata |
+| **Booleans** | Bit-packed | Binary indicators |
+| **Vectors** | All scalar types | Embeddings, feature arrays |
+
+Type conversion is handled by the `datatypeconverter` package with optimized float8 implementations.
+
+---
+
+## Inference Logging
+
+Inferflow supports async inference logging to Kafka for model monitoring and debugging:
+
+### Serialization Formats
+
+| Format | Use Case |
+|--------|----------|
+| **Proto** | Default, compact |
+| **Arrow** | Columnar analytics |
+| **Parquet** | Long-term storage, query-friendly |
+
+### Sampling Controls
+
+| Config | Description |
+|--------|-------------|
+| `LoggingPerc` | Percentage of requests to log (0-100) |
+| `LogBatchSize` | Batch size for log message grouping |
+| `LogFeatures` | Specific features to include in logs |
+
+### Log Content
+
+Each `InferflowLog` message includes:
+- `user_id`, `tracking_id`, `model_config_id`
+- Entity IDs and feature values
+- Model scores and metadata
+
+---
+
+## Configuration Hot-Reload
+
+Model configurations are stored in **etcd** and support **live updates without redeployment**:
+
+1. Inferflow registers watchers on etcd config paths
+2. On config change, watchers trigger `ReloadModelConfigMapAndRegisterComponents`
+3. `ConfigMap` is updated in memory
+4. Feature schemas are re-initialized
+5. DAG components are re-registered
+
+This enables:
+- Adding new models in production without restarts
+- A/B testing with different model configurations
+- Instant rollback by reverting etcd config
+
+---
+
+## Performance Characteristics
+
+### Concurrency Model
+- DAG components at the same level execute concurrently in goroutines
+- Feature retrieval is parallelized across entity types
+- External gRPC calls use connection pooling
+
+### Memory Efficiency
+- Built in Go — significantly lower memory footprint than Java equivalents (~80% reduction)
+- Object pooling for `ComponentMatrix` and serialization buffers
+- In-memory cache with zero-GC-overhead option (freecache)
+
+### Serialization
+- gRPC with Proto3 for all external communication
+- Binary feature encoding in the `ComponentMatrix` for minimal overhead
+- Configurable compression for Kafka logging
+
+---
+
+## Contributing
+
+We welcome contributions from the community! Please see our [Contributing Guide](https://github.com/Meesho/BharatMLStack/blob/main/CONTRIBUTING.md) for details on how to get started.
+
+## Community & Support
+
+- **Discord**: Join our [community chat](https://discord.gg/XkT7XsV2AU)
+- **Issues**: Report bugs and request features on [GitHub Issues](https://github.com/Meesho/BharatMLStack/issues)
+- **Email**: Contact us at [ml-oss@meesho.com](mailto:ml-oss@meesho.com)
+
+## License
+
+BharatMLStack is open-source software licensed under the [BharatMLStack Business Source License 1.1](https://github.com/Meesho/BharatMLStack/blob/main/LICENSE.md).
+
+---
+
+
+ Built with ❤️ for the ML community from Meesho
+
+
+ If you find this useful, ⭐️ the repo — your support means the world to us!
+
diff --git a/docs-src/docs/inferflow/v1.0.0/index.md b/docs-src/docs/inferflow/v1.0.0/index.md
new file mode 100644
index 00000000..abb59d61
--- /dev/null
+++ b/docs-src/docs/inferflow/v1.0.0/index.md
@@ -0,0 +1,14 @@
+---
+title: v1.0.0
+description: Inferflow v1.0.0
+sidebar_position: 0
+slug: /inferflow/v1.0.0
+---
+
+import DocCardList from '@theme/DocCardList';
+
+# Inferflow v1.0.0
+
+Inferflow is a graph-driven feature retrieval and model inference orchestration engine. It dynamically resolves entity relationships via configurable DAGs, retrieves features from the Online Feature Store, and orchestrates model scoring.
+
+
diff --git a/docs-src/docs/inferflow/v1.0.0/release-notes.md b/docs-src/docs/inferflow/v1.0.0/release-notes.md
new file mode 100644
index 00000000..2a73c843
--- /dev/null
+++ b/docs-src/docs/inferflow/v1.0.0/release-notes.md
@@ -0,0 +1,208 @@
+---
+title: Release Notes
+sidebar_position: 4
+---
+
+# Inferflow - Release Notes
+
+## Version 1.0.0
+**Release Date**: June 2025
+**Status**: General Availability (GA)
+
+We're excited to announce the first stable release of **Inferflow** — a graph-driven feature retrieval and model inference orchestration engine, part of BharatMLStack.
+
+---
+
+## What's New
+
+### Config-Driven DAG Executor
+- **No-code feature retrieval**: Onboard new models with config changes only — no custom code required
+- **DAG topology execution**: Define component dependency graphs that are executed concurrently using Kahn's algorithm
+- **Hot reload**: Model configurations stored in etcd are watched and reloaded live — no redeployment needed
+- **DAG caching**: Topologies are cached using Murmur3 hashing with Ristretto for minimal overhead
+
+### Multi-Pattern Inference APIs
+Three structured inference patterns via the Predict API:
+
+| API | Pattern | Use Case |
+|-----|---------|----------|
+| `InferPointWise` | Score each target independently | CTR prediction, fraud scoring |
+| `InferPairWise` | Score pairs of targets | Preference learning, comparison ranking |
+| `InferSlateWise` | Score groups of targets together | Whole-page optimization, diversity-aware ranking |
+
+Plus the entity-based `RetrieveModelScore` API for direct feature retrieval and scoring.
+
+### Component System
+Four built-in component types:
+- **FeatureInitComponent** — Initializes the shared ComponentMatrix
+- **FeatureComponent** — Fetches features from the Online Feature Store (OnFS)
+- **PredatorComponent** — Calls model serving endpoints with percentage-based traffic routing
+- **NumerixComponent** — Calls compute engine for operations like reranking
+
+### Online Feature Store Integration
+- gRPC-based feature retrieval via `FeatureService.RetrieveFeatures`
+- Batched retrieval with configurable batch size and deadline
+- Token-based authentication
+- Dynamic key resolution from the ComponentMatrix
+
+### In-Memory Feature Caching
+- Optional per-component caching to reduce OnFS load
+- Configurable TTL per component
+- Zero-GC-overhead cache option (freecache)
+- Cache hit/miss metrics
+
+### Inference Logging
+- Async logging to Kafka for model monitoring and debugging
+- Three serialization formats: **Proto**, **Arrow**, **Parquet**
+- Configurable sampling rate and feature selection
+- Batched log message grouping
+
+---
+
+## Performance
+
+### Built in Go
+Inferflow is written entirely in Go, delivering:
+- ~80% lower memory usage compared to equivalent Java services
+- Lower CPU utilization
+- Faster, more efficient deployments
+
+### Concurrency
+- DAG components at the same level execute concurrently in goroutines
+- Feature retrieval parallelized across entity types
+- Connection pooling for all external gRPC calls
+
+### Serialization
+- gRPC with Proto3 for all APIs
+- Binary feature encoding in the ComponentMatrix
+- Configurable compression for Kafka logging (ZSTD support)
+
+---
+
+## APIs & Protocols
+
+### gRPC API
+
+**Inferflow Service:**
+```protobuf
+service Inferflow {
+ rpc RetrieveModelScore(InferflowRequestProto) returns (InferflowResponseProto);
+}
+```
+
+**Predict Service:**
+```protobuf
+service PredictService {
+ rpc InferPointWise(PredictRequest) returns (PredictResponse);
+ rpc InferPairWise(PredictRequest) returns (PredictResponse);
+ rpc InferSlateWise(PredictRequest) returns (PredictResponse);
+}
+```
+
+### Data Types Supported
+
+| Type | Variants |
+|------|----------|
+| Integers | int8, int16, int32, int64 |
+| Floats | float8 (e4m3, e5m2), float16, float32, float64 |
+| Strings | Variable length |
+| Booleans | Bit-packed |
+| Vectors | All scalar types |
+
+---
+
+## Enterprise Features
+
+### Production Readiness
+- **Health checks**: HTTP health endpoints via cmux
+- **Graceful shutdown**: Clean resource cleanup
+- **Structured logging**: JSON-formatted logs via zerolog
+- **Signal handling**: SIGTERM/SIGINT support for container environments
+
+### Monitoring & Observability
+- **StatsD / Telegraf integration**: Request rates, latencies, error rates
+- **Per-component metrics**: Execution time, feature counts, cache hit rates
+- **External API metrics**: OnFS, Predator, Numerix call tracking
+- **Kafka logging metrics**: Messages sent, errors
+
+### Configuration Management
+- **etcd-based**: All model configs stored in etcd
+- **Watch & reload**: Live config updates without restart
+- **Multi-model support**: Multiple `model_config_id` entries served concurrently
+
+---
+
+## Deployment
+
+### Container Support
+- **Docker image**: Multi-stage build (Go Alpine builder + Debian runtime)
+- **Optional Kafka**: librdkafka support via build flag
+- **Static binary**: Single binary deployment
+
+### Supported Environments
+- Kubernetes (K8s)
+- Google Kubernetes Engine (GKE)
+- Amazon EKS
+
+---
+
+## Compatibility
+
+### Supported Go Versions
+- **Minimum**: Go 1.19
+- **Recommended**: Go 1.24+
+
+### External Dependencies
+
+| Service | Version | Protocol |
+|---------|---------|----------|
+| etcd | 3.5+ | gRPC |
+| Online Feature Store (OnFS) | 1.0+ | gRPC |
+| Predator (Helix) | 1.0+ | gRPC |
+| Numerix | 1.0+ | gRPC |
+| Kafka | 2.0+ | TCP |
+
+---
+
+## Download & Installation
+
+### Source Code
+```bash
+git clone https://github.com/Meesho/BharatMLStack.git
+cd BharatMLStack/inferflow
+```
+
+### Build
+```bash
+go build -o inferflow-server cmd/inferflow/main.go
+```
+
+### Docker
+```bash
+docker build -t inferflow:latest .
+```
+
+---
+
+## Contributing
+
+We welcome contributions from the community! Please see our [Contributing Guide](https://github.com/Meesho/BharatMLStack/blob/main/CONTRIBUTING.md) for details on how to get started.
+
+## Community & Support
+
+- **Discord**: Join our [community chat](https://discord.gg/XkT7XsV2AU)
+- **Issues**: Report bugs and request features on [GitHub Issues](https://github.com/Meesho/BharatMLStack/issues)
+- **Email**: Contact us at [ml-oss@meesho.com](mailto:ml-oss@meesho.com)
+
+## License
+
+BharatMLStack is open-source software licensed under the [BharatMLStack Business Source License 1.1](https://github.com/Meesho/BharatMLStack/blob/main/LICENSE.md).
+
+---
+
+
+ Built with ❤️ for the ML community from Meesho
+
+
+ If you find this useful, ⭐️ the repo — your support means the world to us!
+
diff --git a/docs-src/docs/intro.md b/docs-src/docs/intro.md
new file mode 100644
index 00000000..4a56ea71
--- /dev/null
+++ b/docs-src/docs/intro.md
@@ -0,0 +1,57 @@
+---
+sidebar_position: 0
+title: BharatMLStack Documentation
+slug: intro
+---
+
+# BharatMLStack Documentation
+
+Welcome to the BharatMLStack documentation. BharatMLStack is an open-source, end-to-end ML infrastructure stack built for scale, speed, and simplicity. Explore the components below to get started.
+
+---
+
+## Quick Start
+
+Get up and running with BharatMLStack in minutes. Step-by-step instructions, sample data, and Docker Compose setup for local development and testing.
+
+**[Go to Quick Start →](/category/quick-start)**
+
+---
+
+## Online Feature Store
+
+Sub-10ms, high-throughput access to machine learning features for real-time inference. Supports batch and streaming ingestion, schema validation, and compact versioned feature groups.
+
+**[Go to Online Feature Store →](/category/online-feature-store)**
+
+---
+
+## Inferflow
+
+Graph-driven feature retrieval and model inference orchestration engine. Dynamically resolves entity relationships, retrieves features, and orchestrates model scoring — all without custom code.
+
+**[Go to Inferflow →](/category/inferflow)**
+
+---
+
+## Trufflebox UI
+
+Modern, feature-rich UI framework for MLOps management. Supports feature catalog, user management, and admin operations with approval flows.
+
+**[Go to Trufflebox UI →](/category/trufflebox-ui)**
+
+---
+
+## SDKs
+
+Client libraries for Go and Python to interact with the Online Feature Store and other platform components. Includes gRPC clients, REST APIs, and Apache Spark integration.
+
+**[Go to SDKs →](/category/sdks)**
+
+---
+
+## Numerix
+
+High-performance compute engine for ultra-fast element-wise matrix operations. Built in Rust with SIMD acceleration for sub-5ms p99 latency.
+
+**[Go to Numerix →](/category/numerix)**
diff --git a/docs-src/docs/numerix/_category_.json b/docs-src/docs/numerix/_category_.json
index 7c2d4af0..2340ae40 100644
--- a/docs-src/docs/numerix/_category_.json
+++ b/docs-src/docs/numerix/_category_.json
@@ -1,6 +1,6 @@
{
"label": "Numerix",
- "position": 6,
+ "position": 7,
"link": {
"type": "generated-index",
"description": "Numerix is a mathematical compute engine for BharatML Stack. It is used to perform mathematical operations on matrices and vectors."
diff --git a/docs-src/docs/numerix/v1.0.0/_category_.json b/docs-src/docs/numerix/v1.0.0/_category_.json
index 4748f653..66455a9e 100644
--- a/docs-src/docs/numerix/v1.0.0/_category_.json
+++ b/docs-src/docs/numerix/v1.0.0/_category_.json
@@ -1,10 +1,5 @@
{
"label": "v1.0.0",
- "position": 1,
- "link": {
- "type": "generated-index",
- "description": "Numerix v1.0.0",
- "slug": "/numerix/v1.0.0"
- }
+ "position": 1
}
diff --git a/docs-src/docs/numerix/v1.0.0/index.md b/docs-src/docs/numerix/v1.0.0/index.md
new file mode 100644
index 00000000..1307fef7
--- /dev/null
+++ b/docs-src/docs/numerix/v1.0.0/index.md
@@ -0,0 +1,14 @@
+---
+title: v1.0.0
+description: Numerix v1.0.0
+sidebar_position: 0
+slug: /numerix/v1.0.0
+---
+
+import DocCardList from '@theme/DocCardList';
+
+# Numerix v1.0.0
+
+Numerix is a mathematical compute engine for BharatML Stack. It is used to perform mathematical operations on matrices and vectors.
+
+
diff --git a/docs-src/docs/online-feature-store/v1.0.0/_category_.json b/docs-src/docs/online-feature-store/v1.0.0/_category_.json
index 4fec8dcc..4e1f685c 100644
--- a/docs-src/docs/online-feature-store/v1.0.0/_category_.json
+++ b/docs-src/docs/online-feature-store/v1.0.0/_category_.json
@@ -1,9 +1,4 @@
{
- "label": "v1.0.0",
- "position": 1,
- "link": {
- "type": "generated-index",
- "description": "Online Feature Store v1.0.0",
- "slug": "/online-feature-store/v1.0.0"
- }
+ "label": "v1.0.0",
+ "position": 1
}
\ No newline at end of file
diff --git a/docs-src/docs/online-feature-store/v1.0.0/index.md b/docs-src/docs/online-feature-store/v1.0.0/index.md
new file mode 100644
index 00000000..b790c081
--- /dev/null
+++ b/docs-src/docs/online-feature-store/v1.0.0/index.md
@@ -0,0 +1,14 @@
+---
+title: v1.0.0
+description: Online Feature Store v1.0.0
+sidebar_position: 0
+slug: /online-feature-store/v1.0.0
+---
+
+import DocCardList from '@theme/DocCardList';
+
+# Online Feature Store v1.0.0
+
+A high-performance, scalable, and production-grade feature store built for modern machine learning systems. It supports both real-time and batch workflows, with low-latency feature retrieval.
+
+
diff --git a/docs-src/docs/predator/_category_.json b/docs-src/docs/predator/_category_.json
new file mode 100644
index 00000000..576eb122
--- /dev/null
+++ b/docs-src/docs/predator/_category_.json
@@ -0,0 +1,8 @@
+{
+ "label": "Predator",
+ "position": 7,
+ "link": {
+ "type": "generated-index",
+ "description": "Predator is a scalable, high-performance model inference service built as a wrapper around NVIDIA Triton Inference Server, designed to serve ML models with low latency in Kubernetes, with OnFS and Interflow integration."
+ }
+}
diff --git a/docs-src/docs/predator/v1.0.0/_category_.json b/docs-src/docs/predator/v1.0.0/_category_.json
new file mode 100644
index 00000000..3c72a212
--- /dev/null
+++ b/docs-src/docs/predator/v1.0.0/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "v1.0.0",
+ "position": 1
+}
diff --git a/docs-src/docs/predator/v1.0.0/architecture.md b/docs-src/docs/predator/v1.0.0/architecture.md
new file mode 100644
index 00000000..e337ae4f
--- /dev/null
+++ b/docs-src/docs/predator/v1.0.0/architecture.md
@@ -0,0 +1,201 @@
+---
+title: Architecture
+sidebar_position: 1
+---
+
+# BharatMLStack - Predator
+
+Predator is a scalable, high-performance model inference service built as a wrapper around the **NVIDIA Triton Inference Server**. It is designed to serve a variety of machine learning models (Deep Learning, Tree-based, etc.) with low latency in a **Kubernetes (K8s)** environment.
+
+The system integrates seamlessly with the **Online Feature Store (OnFS)** for real-time feature retrieval and uses **Horizon** as the deployment orchestration layer. Deployments follow a **GitOps** pipeline — Horizon generates Helm configurations, commits them to GitHub, and **Argo Sync** reconciles the desired state onto Kubernetes.
+
+---
+
+## High-Level Design
+
+
+
+### End-to-End Flow
+
+1. **Model Deployment Trigger**: An actor initiates deployment through **Trufflebox UI**, specifying the GCS path (`gcs://`) of the trained model. Separately, post-training pipelines write model artifacts to **GCS Artifactory**.
+
+2. **Orchestration via Horizon**: Trufflebox UI communicates with **Horizon**, the deployment orchestration layer. Horizon generates the appropriate **Helm** chart configuration for the inference service.
+
+3. **GitOps Pipeline**: Horizon commits the Helm values to a **GitHub** repository. **Argo Sync** watches the repo and reconciles the desired state onto the Kubernetes cluster, creating or updating deployable units.
+
+4. **Deployable Units (Deployable 1 … N)**: Each deployable is an independent Kubernetes deployment that:
+ - Downloads model artifacts from **GCS** at startup via an `init.sh` script.
+ - Launches a **Triton Inference Server** instance loaded with the model.
+ - Runs one or more pods, each containing the inference runtime and configured backends.
+
+5. **Triton Backends**: Each Triton instance supports pluggable backends based on the model type:
+ - **FIL** — GPU-accelerated tree-based models (XGBoost, LightGBM, Random Forest).
+ - **PyTorch** — Native PyTorch models via LibTorch.
+ - **Python** — Custom preprocessing/postprocessing or unsupported model formats.
+ - **TRT (TensorRT)** — GPU-optimized serialized TensorRT engines.
+ - **ONNX** — Framework-agnostic execution via ONNX Runtime.
+ - **DALI** — GPU-accelerated data preprocessing (image, audio, video).
+
+6. **Autoscaling with KEDA**: The cluster uses **KEDA** (Kubernetes Event-Driven Autoscaling) to scale deployable pods based on custom metrics (CPU utilization, GPU utilization via DCGM, queue depth, etc.). The underlying **Kubernetes** scheduler places pods across GPU/CPU node pools.
+
+### Key Design Principles
+
+- **GitOps-driven**: All deployment state is version-controlled in Git; Argo Sync ensures cluster state matches the declared configuration.
+- **Isolation per deployable**: Each model or model group gets its own deployable unit, preventing noisy-neighbor interference.
+- **Init-based model loading**: Models are materialized to local disk before Triton starts, ensuring deterministic startup and no runtime dependency on remote storage.
+- **Pluggable backends**: The same infrastructure serves deep learning, tree-based, and custom models through Triton's backend abstraction.
+
+---
+
+## Inference Engine: Triton Inference Server
+
+NVIDIA Triton Inference Server is a high-performance model serving system designed to deploy ML and deep learning models at scale across CPUs and GPUs. It provides a unified inference runtime that supports multiple frameworks, optimized execution, and production-grade scheduling.
+
+Triton operates as a standalone server that loads models from a model repository and exposes standardized HTTP/gRPC APIs. Predator uses **gRPC** for efficient request and response handling via the **helix client**.
+
+### Core Components
+
+- **Model Repository**: Central directory where models are stored. Predator typically materializes the model repository onto local disk via an init container, enabling fast model loading and eliminating runtime dependency on remote storage during inference.
+
+### Backends
+
+A backend is the runtime responsible for executing a model. Each model specifies which backend runs it via configuration.
+
+| Backend | Description |
+|---------|-------------|
+| **TensorRT** | GPU-optimized; executes serialized TensorRT engines (kernel fusion, FP16/INT8). |
+| **PyTorch** | Serves native PyTorch models via LibTorch. |
+| **ONNX Runtime** | Framework-agnostic ONNX execution with TensorRT and other accelerators. |
+| **TensorFlow** | Runs TensorFlow SavedModel format. |
+| **Python backend** | Custom Python code for preprocessing, postprocessing, or unsupported models. |
+| **Custom backends** | C++/Python backends for specialized or proprietary runtimes. |
+| **DALI** | GPU-accelerated data preprocessing (image, audio, video). |
+| **FIL (Forest Inference Library)** | GPU-accelerated tree-based models (XGBoost, LightGBM, Random Forest). |
+
+### Key Features
+
+- **Dynamic batching**: Combines multiple requests into a single batch at runtime — higher GPU utilization, improved throughput, reduced latency variance.
+- **Concurrent model execution**: Run multiple models or multiple instances of the same model; distribute load across GPUs.
+- **Model versioning**: Support multiple versions per model.
+- **Ensemble models**: Pipeline of models as an ensemble; eliminates intermediate network hops, reduces latency.
+- **Model instance scaling**: Multiple copies of a model for parallel inference and load isolation.
+- **Observability**: Prometheus metrics, granular latency, throughput, GPU utilization.
+- **Warmup requests**: Preload kernels and avoid cold-start latency.
+
+---
+
+## Model Repository Structure
+
+```
+model_repository/
+├── model_A/
+│ ├── config.pbtxt
+│ ├── 1/
+│ │ └── model.plan
+│ ├── 2/
+│ │ └── model.plan
+├── model_B/
+│ ├── config.pbtxt
+│ ├── 1/
+│ └── model.py
+```
+
+The `config.pbtxt` file defines how Triton loads and executes a model: input/output tensors, batch settings, hardware execution, backend runtime, and optimization parameters. At minimum it defines: `backend/platform`, `max_batch_size`, `inputs`, `outputs`.
+
+### Sample config.pbtxt
+
+```text
+name: "product_ranking_model"
+platform: "tensorrt_plan"
+max_batch_size: 64
+input [ { name: "input_embeddings" data_type: TYPE_FP16 dims: [ 128 ] }, { name: "context_features" data_type: TYPE_FP32 dims: [ 32 ] } ]
+output [ { name: "scores" data_type: TYPE_FP32 dims: [ 1 ] } ]
+instance_group [ { kind: KIND_GPU count: 2 gpus: [0] } ]
+dynamic_batching { preferred_batch_size: [8,16,32,64] max_queue_delay_microseconds: 2000 }
+```
+
+---
+
+## Kubernetes Deployment Architecture
+
+Predator inference services are deployed on Kubernetes using **Helm-based** deployments for standardized, scalable, GPU-optimized model serving. Each deployment consists of Triton Inference Server wrapped within a Predator runtime, with autoscaling driven by CPU and GPU utilization.
+
+### Pod Architecture
+
+```
+Predator Pod
+├── Init Container (Model Sync)
+├── Triton Inference Server Container
+```
+
+Model artifacts and runtime are initialized before inference traffic is accepted.
+
+#### Init Container
+
+- Download model artifacts from cloud storage (GCS).
+- Populate the Triton model repository directory.
+- Example: `gcloud storage cp -r gs://.../model-path/* /models`
+
+Benefits: deterministic startup (Triton starts only after models are available), separation of concerns (image = runtime, repository = data).
+
+#### Triton Inference Server Container
+
+- Load model artifacts from local repository.
+- Manage inference scheduling, request/response handling, and expose inference endpoints.
+
+### Triton Server Image Strategy
+
+The Helm chart uses the Triton container image from the internal **artifact registry**. Production uses **custom-built** images (only required backends, e.g. TensorRT, Python) to reduce size and startup time. Unnecessary components are excluded; images are built internally and pushed to the registry.
+
+**Response Caching**: Custom cache plugins can be added at image build time for optional inference response caching — reducing redundant execution and GPU use for repeated inputs.
+
+### Image Distribution Optimization
+
+- **Secondary boot disk image caching**: Images are pre-cached on GPU node pool secondary boot disks to avoid repeated pulls during scale-up and reduce pod startup time and cold-start latency.
+- **Image streaming**: Can be used to progressively pull layers for faster time-to-readiness during scaling.
+
+### Health Probes
+
+Readiness and liveness use `/v2/health/ready`. Triton receives traffic only after model loading; failed instances are restarted automatically.
+
+### Resource Configuration
+
+Sample GPU resource config:
+
+```yaml
+limits:
+ cpu: 7000m
+ memory: 28Gi
+ gpu: 1
+```
+
+### Autoscaling Architecture
+
+Predator uses **KEDA** (Kubernetes Event-Driven Autoscaling) for scaling deployable pods. KEDA supports custom metric sources including:
+
+- **CPU / Memory utilization** for CPU-based deployments.
+- **GPU utilization** via **DCGM** (Data Center GPU Manager) for GPU pods — covering utilization, memory, power, etc.
+- **Custom Prometheus queries** for application-level scaling signals (e.g., inference queue depth, request latency).
+
+KEDA ScaledObjects are configured per deployable, enabling fine-grained, independent scaling for each model or model group.
+
+---
+
+## Contributing
+
+We welcome contributions! See the [Contributing Guide](https://github.com/Meesho/BharatMLStack/blob/main/CONTRIBUTING.md).
+
+## Community & Support
+
+- **Discord**: [community chat](https://discord.gg/XkT7XsV2AU)
+- **Issues**: [GitHub Issues](https://github.com/Meesho/BharatMLStack/issues)
+- **Email**: [ml-oss@meesho.com](mailto:ml-oss@meesho.com)
+
+## License
+
+BharatMLStack is open-source under the [BharatMLStack Business Source License 1.1](https://github.com/Meesho/BharatMLStack/blob/main/LICENSE.md).
+
+---
+
+
Built with ❤️ for the ML community from Meesho
+
If you find this useful, ⭐️ the repo — your support means the world to us!
diff --git a/docs-src/docs/predator/v1.0.0/functionalities.md b/docs-src/docs/predator/v1.0.0/functionalities.md
new file mode 100644
index 00000000..e5f90b7c
--- /dev/null
+++ b/docs-src/docs/predator/v1.0.0/functionalities.md
@@ -0,0 +1,119 @@
+---
+title: Key Functionalities
+sidebar_position: 2
+---
+
+# Predator - Key Functionalities
+
+## Overview
+
+Predator is a scalable, high-performance model inference service built as a wrapper around **NVIDIA Triton Inference Server**. It serves Deep Learning and tree-based models with low latency in **Kubernetes**, integrates with the **Online Feature Store (OnFS)** and uses **Interflow** for orchestration between clients, feature store, and inference engine. Clients send inference requests via the **Helix client** over gRPC.
+
+---
+
+## Core Capabilities
+
+### Multi-Backend Inference
+
+Predator leverages Triton's pluggable backends so you can serve a variety of model types from a single deployment:
+
+| Backend | Use Case |
+|---------|----------|
+| **TensorRT** | GPU-optimized DL; serialized engines (FP16/INT8) |
+| **PyTorch** | Native PyTorch via LibTorch |
+| **ONNX Runtime** | Framework-agnostic ONNX with TensorRT/GPU |
+| **TensorFlow** | SavedModel format |
+| **Python** | Custom preprocessing, postprocessing, or unsupported models |
+| **FIL** | Tree-based models (XGBoost, LightGBM, Random Forest) on GPU |
+| **DALI** | GPU-accelerated data preprocessing (image, audio, video) |
+| **Custom** | C++/Python backends for proprietary or specialized runtimes |
+
+### Dynamic Batching
+
+Triton combines multiple incoming requests into a single batch at runtime.
+
+- Higher GPU utilization and improved throughput
+- Reduced latency variance
+- Configurable `preferred_batch_size` and `max_queue_delay_microseconds` in `config.pbtxt`
+
+### Concurrent Model Execution
+
+- Run multiple models simultaneously
+- Run multiple instances of the same model
+- Distribute load across GPUs via `instance_group` in model config
+
+### Model Versioning & Ensembles
+
+- **Versioning**: Multiple versions per model (e.g. `1/`, `2/` in the model repository)
+- **Ensembles**: Define a pipeline of models as an ensemble; eliminates intermediate network hops and reduces latency
+
+### Model Instance Scaling
+
+- Deploy multiple copies of a model for parallel inference and load isolation
+- Configured via `instance_group`
+
+---
+
+## Inference & API
+
+### gRPC via Helix Client
+
+Predator uses **gRPC** for efficient request/response handling. Client applications (e.g. Realestate, IOP) send inference requests through the **Helix client**, which talks to the Triton Inference Server inside the Predator pod.
+
+### Model Repository
+
+Models are stored in a local model repository. Predator materializes this via an **Init Container** that downloads artifacts from cloud storage (e.g. GCS) so Triton has no runtime dependency on remote storage during inference.
+
+---
+
+## Deployment & Operational Features
+
+### Custom Triton Images
+
+- Production uses **custom-built** Triton images (only required backends) for smaller size and faster startup
+- Images built on GCP VM, pushed to **Artifact Registry**, and referenced in Helm deployments
+- Optional **response caching** via custom cache plugins added at image build time
+
+### Image Distribution
+
+- **Secondary boot disk caching**: Triton image pre-cached on GPU node pool to reduce pod startup and scale-up latency
+- **Image streaming**: Optionally used for faster time-to-readiness during scaling
+
+### Health Probes
+
+- Readiness and liveness use `/v2/health/ready`
+- Triton receives traffic only after models are loaded; failed instances are restarted automatically
+
+### Autoscaling
+
+- CPU-based scaling for generic load
+- GPU-based scaling using **DCGM** metrics (utilization, memory, power); custom queries drive scale-up/scale-down
+
+---
+
+## Observability
+
+- **Prometheus metrics**: Latency, throughput, GPU utilization, and more
+- Metrics emitted from the Triton Inference Container and visualized in **Grafana**
+- **Warmup requests**: Configurable to preload kernels and avoid cold-start latency
+
+---
+
+## Contributing
+
+We welcome contributions! See the [Contributing Guide](https://github.com/Meesho/BharatMLStack/blob/main/CONTRIBUTING.md).
+
+## Community & Support
+
+- **Discord**: [community chat](https://discord.gg/XkT7XsV2AU)
+- **Issues**: [GitHub Issues](https://github.com/Meesho/BharatMLStack/issues)
+- **Email**: [ml-oss@meesho.com](mailto:ml-oss@meesho.com)
+
+## License
+
+BharatMLStack is open-source under the [BharatMLStack Business Source License 1.1](https://github.com/Meesho/BharatMLStack/blob/main/LICENSE.md).
+
+---
+
+
Built with ❤️ for the ML community from Meesho
+
If you find this useful, ⭐️ the repo — your support means the world to us!
Open source, end-to-end ML infrastructure stack built for scale, speed, and simplicity.
+ Integrate, deploy, and manage robust ML workflows with full reliability and control.
- BharatMLStack is a comprehensive, production-ready machine learning infrastructure
- platform designed to democratize ML capabilities across India and beyond. Our mission
- is to provide a robust, scalable, and accessible ML stack that empowers organizations
- to build, deploy, and manage machine learning solutions at massive scale.
-
-
- Explore Online Feature Store →
-
-
-
-
-
🏆 Key Achievements
-
-
✅ Sub-10ms P99 latency for real-time inference
-
✅ 1M+ RPS tested with 100 IDs per request
-
✅ PSDB format outperforms Proto3 & Arrow
-
✅ Multi-database: Scylla, Dragonfly, Redis
-
✅ Production-ready with comprehensive monitoring
+
+
+
+
Why BharatMLStack
+
The Real Barriers to Scaling Machine Learning
+
+ ML teams spend more time fighting infrastructure than building intelligence.
+ BharatMLStack removes those barriers.
+
- Trufflebox UI provides a comprehensive, modern web interface for managing your entire
- ML infrastructure. Built with cutting-edge web technologies, it delivers an intuitive
- experience for feature management, user administration, and operational oversight.
- Streamline your MLOps workflows with enterprise-grade UI components.
-
-
- Explore Trufflebox UI →
-
-
-
-
-
🎨 UI Features
-
-
✅ Comprehensive feature catalog & discovery
-
✅ Role-based access control & user management
-
✅ Job, Store, Admin Ops management
-
✅ Approval flow for everything
-
✅ Responsive design for desktop & mobile
-
+
+
+
+
Platform Components
+
BharatMLStack Components
+
+ Purpose-built components for every stage of the ML lifecycle, from feature
+ serving to model deployment.
+
- Our SDKs are designed with developers in mind, providing idiomatic APIs for Go and Python
- that feel natural in your existing codebase. Whether you're building microservices,
- data pipelines, or ML applications, our SDKs provide the tools you need for seamless
- integration with BharatMLStack's powerful infrastructure.
-
-
- Explore SDKs →
-
-
-
-
-
🛠️ Developer Tools
-
-
✅ Native Go & Python SDKs with type safety
-
✅ High-performance gRPC
-
✅ Apache Spark integration for publishing features
+ 
+ 
+ 
}){kind=logo}
- }){kind=logo}
+
-
-
-
-
-
-
);
}
-function TruffleboxAbout() {
+function ComponentsSection() {
+ const cardsRef = useRef([]);
+ const baseUrl = useBaseUrl('/');
+
+ useEffect(() => {
+ const observer = new IntersectionObserver(
+ (entries) => {
+ entries.forEach((entry) => {
+ if (entry.isIntersecting) {
+ entry.target.classList.add(styles.componentCardVisible);
+ }
+ });
+ },
+ { threshold: 0.1, rootMargin: '0px 0px -80px 0px' }
+ );
+
+ cardsRef.current.forEach((card) => {
+ if (card) observer.observe(card);
+ });
+
+ return () => observer.disconnect();
+ }, []);
+
return (
-