SearcharxivSearch

arXiv subjects

Matteo Collina

Publications and source records attributed to Matteo Collina.

3 recordsLinked to original sources

A Telemetry-Driven Model for Quantifying Upgrade Risk in Durable Workflow Execution

Durable workflow engines reconstruct execution state by deterministically replaying an immutable event log, coupling every in-flight run to the code version that produced its history: a new deployment can invalidate the replay of runs started under the old version, silently corrupting state or halting progress. Existing mitigations -- pinning, patch gates, side-by-side deployment -- treat every change as maximally dangerous and drain old versions, untenable for workflows that sleep for weeks. We present a closed-form probabilistic model that quantifies the risk of upgrading in-flight runs from workflow version $V_1$ to $V_2$ using only a static structural diff and telemetry the protocol already persists -- event logs, step payloads, historical paths -- with no dry-run, sandbox, or shadow execution. Risk decomposes along three axes (protocol, interface, state migration) and combines an exact backward (rehydration) term, computed on recorded prefixes modulo trace equivalence of concurrent completions, with a probabilistic forward term from hitting probabilities in an empirically estimated Markov model of control flow. Estimation is Bayesian throughout, so the Workflow Upgrade Risk (WUR) score carries a credible interval and thin telemetry surfaces as uncertainty. We prove that a zero backward-risk verdict certifies safe rehydration under the new version, and derive a policy partitioning runs into migrate, review, and pin classes. Finally we drop the inter-run independence assumption: coupling through hooks, hierarchy, and shared resources is captured by an empirical coupling graph, fleet risk becomes the least fixpoint of a failure-contagion operator, and the coupling-aware migrate/pin partition is computed exactly as a minimum s-t cut.

cs.SE

Predictive Autoscaling for Node.js on Kubernetes: Lower Latency, Right-Sized Capacity

Kubernetes offers two default paths for scaling Node\.js workloads, and both have structural limitations. The Horizontal Pod Autoscaler scales on CPU utilization, which does not directly measure event loop saturation: a Node.js pod can queue requests and miss latency SLOs while CPU reports moderate usage. KEDA extends HPA with richer triggers, including event-loop metrics, but inherits the same reactive control loop, detecting overload only after it has begun. By the time new pods start and absorb traffic, the system may already be degraded. Lowering thresholds shifts the operating point but does not change the dynamic: the scaler still reacts to a value it has already crossed, at the cost of permanent over-provisioning. We propose a predictive scaling algorithm that forecasts where load will be by the time new capacity is ready and scales proactively based on that forecast. Per-instance metrics are corrupted by the scaler's own actions: adding an instance redistributes load and changes every metric, even if external traffic is unchanged. We observe that operating on a cluster-wide aggregate that is approximately invariant under scaling eliminates this feedback loop, producing a stable signal suitable for short-term extrapolation. We define a metric model (a set of three functions that encode how a specific metric relates to scaling) and a five-stage pipeline that transforms raw, irregularly-timed, partial metric data into a clean prediction signal. In benchmarks against HPA and KEDA under steady ramp and sudden spike, the algorithm keeps per-instance load near the target threshold throughout. Under the steady ramp, median latency is 26ms, compared to 154ms for KEDA and 522ms for HPA.

cs.SE

Evaluating the Risk of Changes in a Microservices Architecture

In a microservices-based system, reliability and availability are key components to guarantee the best-in-class experience for the consumers. One of the key advantages of microservices architecture is the ability to independently deploy services, providing maximum change flexibility. However, this introduces an extra complexity in managing the risk associated with every change: any mutation of a service might cause the whole system to fail. In this research, we would propose an algorithm to enable development teams to determine the risk associated with each change to any of the microservices in the system.

cs.SE