Systems Engineer · Mobile Architect · Open-Source Builder · Privacy-First Software · Minecraft Systems Developer

A systems-oriented engineering portfolio focused on event-driven architecture, stateless backend design, and modular runtime systems. This profile operates as a live engineering system dashboard with automated data pipelines, deterministic scoring, and real-time metric updates.

Auto-generated via GitHub Actions (Data Pipeline v3, 6-hourly refresh)

Platform Status:    🟢 Online
Last Update:        Via pipeline-generated metrics
Pipeline Version:   v3.0.0
Cache Status:       Optimized
API Integration:    Active
Update Frequency:   Every 6 hours (scheduled)

• Backend = Orchestration, Not Authority — Backend services orchestrate workflows without owning data
• Events = Primary Primitive — Event-driven flows as first-class design element
• Storage = External & User-Owned — Data lives with users, not in backend
• Failure = Design Constraint — Resilience embedded in architecture
• Modularity > Monoliths — Composition over integration

┌─────────────────────────────────────────────────────────────────┐
│                    GitHub API Ingestion Layer                    │
│         (Fetch repos, normalize schema, rate-limit cache)        │
└────────────────────────┬────────────────────────────────────────┘
                         │
┌────────────────────────▼────────────────────────────────────────┐
│                 Normalization Layer                              │
│        (Standardize repository schemas, validate fields)        │
└────────────────────────┬────────────────────────────────────────┘
                         │
┌────────────────────────▼────────────────────────────────────────┐
│                   Cache Layer                                    │
│         (Rate-limit protection, 6-hour TTL strategy)            │
└────────────────────────┬────────────────────────────────────────┘
                         │
┌────────────────────────▼────────────────────────────────────────┐
│              Scoring Engine v3                                   │
│  score = (stars×3) + (forks×2) + (recency×10)                   │
│        + (language×5) + activity_bonus                          │
└────────────────────────┬────────────────────────────────────────┘
                         │
┌────────────────────────▼────────────────────────────────────────┐
│           Classification Engine                                  │
│   (Categorize: minecraft, automation, product, infra, data)    │
└────────────────────────┬────────────────────────────────────────┘
                         │
┌────────────────────────▼────────────────────────────────────────┐
│        Ranking & Top-N Selection                                 │
│        (Filter forked/archived, rank by score, select top 6)    │
└────────────────────────┬────────────────────────────────────────┘
                         │
┌────────────────────────▼────────────────────────────────────────┐
│         Rendering Layer & Injection Engine                       │
│    (Generate system cards, inject into README, commit changes)  │
└─────────────────────────────────────────────────────────────────┘

• Trigger: Scheduled cron every 6 hours + manual dispatch
• Concurrency: Single-instance protection (no race conditions)
• Execution:
  1. Checkout repository
  2. Setup Node.js 20
  3. Execute Data Pipeline v3 (scoring, classification, ranking)
  4. Render system cards
  5. Inject into README between markers
  6. Idempotent commit (only if changes detected)
  7. Push to main branch

Dynamically ranked via Data Pipeline v3 scoring engine (every 6 hours)

Build Status:               [ 🔄 Running via GitHub Actions ]
Latest Pipeline Run:        Every 6 hours
Deployment Frequency:       Continuous (on main branch)
Last Successful Pipeline:   Auto-tracked

Component	Badge	Status
GitHub Actions		✓ Active
Release Channel		Latest
Last Commit		Live
Repo Size		—

• Method: REST API v3 with rate-limit aware caching
• Authentication: Token-based (GITHUB_TOKEN)
• Rate Limit: 60 req/hr unauthenticated, 5000/hr authenticated
• Cache Strategy: 6-hour TTL for repo data, 24-hour for user profile
• Failure Handling: Graceful degradation with cached fallback

• Workflow: pinned-repos.yml (Data Pipeline v3 orchestration)
• Schedule: 0 */6 * * * (every 6 hours)
• Runtime: Ubuntu latest + Node.js 20
• Permissions: contents: write (README modification)
• Idempotency: Commit only on actual changes

• Primary: Go, Rust, TypeScript, Python
• Mobile: Flutter, Swift, Kotlin
• Game: Java (Paper/Spigot), C#
• Scripting: Node.js, Bash

• Event-driven systems (message queues, event streams)
• Microservices & service mesh (orchestration focus)
• Serverless/FaaS (stateless, event-triggered)
• Plugin architectures (Minecraft, Discord)
• Data pipeline orchestration (ETL/ELT patterns)

• CI/CD: GitHub Actions (primary workflow automation)
• Containerization: Docker, container registries
• Version Control: Git workflow, branching strategies
• Monitoring: GitHub API insights, runtime metrics
• Infrastructure Code: Terraform, CloudFormation patterns

• Active Development: High-frequency updates across systems
• Domain Focus: Backend services, event systems, cross-platform mobile
• Open Source Contribution: Community-driven plugins and tools
• Architecture Research: Exploring edge-optimized, distributed patterns

• Deterministic scoring system ✓
• Automated data pipeline ✓
• Rate-limit aware caching ✓
• Idempotent deployments ✓
• Schema normalization ✓
• Graceful error handling ✓

Interested in event-driven systems, cross-platform engineering, or Minecraft plugin architecture?

• 📧 Reach out: GitHub Issues or Discussions
• 🔗 Connect: GitHub Profile
• 🌐 Explore: Featured projects (auto-ranked above)

Type: Stateless Event Pipeline Model: BYO Storage

Core Flow

Client → Event → Transformation Layer → External Storage

Capabilities

• Google Sheets integration
• Notion / Airtable adapters
• Webhook-based pipelines

Status: Production

Type: Flutter-based UX system Model: Lightweight backend coupling

Capabilities

• Cross-platform mobile runtime
• Event-driven UI state transitions
• Minimal backend dependency design

Status: Published App

Type: JVM runtime system Model: Event-driven plugin kernel

Runtime Architecture

Minecraft Server
  → Bukkit Event System
  → Internal EventBus
  → Module System
  → Gameplay / World Effects

Modules

• Player System
• World System
• Command System
• Integration Layer

Status: Active Development

Fully automated GitHub ranking engine. Repositories are scored, classified, and rendered as structured system cards (not simple markdown lists).

Each repository is evaluated using a weighted scoring model:

score = (stars * 3) + (forks * 2) + recency_boost + language_weight

• Recency Boost: newer updates increase ranking priority

• Language Weight:

  • Rust / Java / Kotlin → high (systems layer)
  • Dart / Flutter → medium (product layer)
  • JS/TS → baseline (web automation)

• Project Type Inference:

  • Minecraft plugin → runtime system
  • Discord bot → event automation system
  • Streaming server → infrastructure system

1. Fetch repositories via GitHub API
2. Filter forks and low-signal repositories
3. Compute composite ranking score
4. Infer project category via heuristics
5. Sort by final score (descending)
6. Render structured system cards into README

• Source: GitHub REST API v4
• Engine: Ranking Engine v2 (weighted scoring model)
• Execution: GitHub Actions scheduled workflow
• Update Frequency: every 6 hours
• Output: Structured system-card injection into README

Real-time plugin + server health layer (powered by GitHub Actions + Shields.io)

• Runtime Integrity: live via GitHub Actions pipeline

All systems are governed by CI-driven automation:

• GitHub Actions build verification
• Gradle-based JVM compilation
• Flutter build validation
• Automated artifact generation
• Release tagging via semantic versioning (planned extension)

Client Event → Processing Layer → External State → Stateless Core

• No persistent backend authority
• Externalized storage ownership
• Deterministic transformation layers
• Modular runtime boundaries

• Primary system primitive
• Fully decoupled components

• User-owned persistence
• No internal database authority

• JVM (Minecraft)
• Flutter (Mobile)
• Node/Webhook integrations

• Backend systems are non-authoritative
• Client is source of truth
• External storage is replaceable
• Failures are expected and handled explicitly
• Minimal attack surface via stateless design

• Website: https://zviel.com/
• Email: mailto:conatct@zviel.com
• LinkedIn: https://www.linkedin.com/in/zvielkoren
• Discord: zvicraft

Systems should minimize centralized ownership while maximizing composability, autonomy, and long-term architectural independence.