The core challenge: • ~1,200 domain-specific metrics • All rule-based (no ML), fully deterministic • Metrics share common primitives but differ in configuration • Metrics combine into composite indices • Outputs must be auditable and reproducible (same inputs → same outputs) • I want metrics definable declaratively (not hard-coded one by one)
The system ingests structured event data, computes per-entity metrics, and produces ranked outputs with full breakdowns.
I’m specifically looking for guidance on: • Architectures for large configurable rule/metric engines • How to represent metric definitions (DSL vs JSON/YAML vs expression trees) • Managing performance without sacrificing transparency • Avoiding “1,200 custom functions” antipatterns • What you’d do differently if starting this today
Cost / effort sanity check (important): If you were scoping this as a solo engineer or small team, what are the biggest cost drivers and realistic milestones? • What should “Phase 1” include to validate the engine (e.g., primitives + declarative metric format + compute pipeline + 100–200 metrics)? • What’s a realistic engineering effort range for Phase 1 vs “all 1,200” (weeks/months, 1–2 devs vs 3–5 devs)? • Any common traps that make cost explode (data modeling mistakes, premature UI, overengineering the DSL, etc.)?
I’m not looking to hire here — just trying to sanity-check design decisions and expected effort before implementation.
Thanks in advance for any insight.
crosslayer•3w ago
When you have ~1,200 deterministic metrics sharing primitives, the real cost driver becomes definition coupling, not execution. If metrics are “configurable” but allowed to encode control flow, branching semantics, or hidden normalization rules, you end up with 1,200 soft-coded functions anyway… just harder to reason about.
One approach that’s worked well for me is to explicitly separate:
• Primitive signals (pure, immutable, versioned) • Metric transforms (strictly functional, no side effects, no cross-metric reads) • Aggregation/composition layers (where ranking and composite indices live)
The key constraint… metric definitions must be referentially transparent and evaluable in isolation. If a metric can’t be recomputed offline from recorded inputs and its definition hash, it’s already too powerful.
On representation… I’ve had better outcomes with a constrained expression tree (or typed DSL) than raw JSON/YAML. The goal isn’t flexibility… it’s preventing the system from becoming a general purpose programming environment.
For Phase 1, I’d strongly cap scope at:
• A small, fixed primitive vocabulary • 100–200 metrics max • Explicit versioning + replay tooling • Hard limits on metric execution cost
The biggest cost explosions I’ve seen come from
• Allowing metrics to depend on other metrics implicitly • Letting “configuration” evolve without versioned invariants • Optimizing performance before semantic boundaries are locked
Curious whether you’re thinking about definition immutability and replayability as first class constraints, or treating them as implementation details later.