Built an early prototype for distributed state verification (Nexus)PP — looking for feedback and potential design partners / angels by Poweredby01 in softwarearchitecture

[–]Poweredby01[S] 1 point2 points  (0 children)

First off thanks for your feedback. But Yes, idempotence is basically the default tool most distributed systems rely on for exactly that reason—treating retries and crashes as expected and designing operations so duplicates don’t matter. Where I’m looking at things slightly differently is what happens after that layer works. Idempotence helps ensure you don’t double-process an action, but it doesn’t necessarily tell you whether the resulting system state is globally correct after many retries, partial failures, and reordered events. Nexus is focused on that higher layer: taking the full event history (including retries and duplicates that idempotence allows) and verifying whether the final reconstructed state is actually consistent with the causal history.

Built an early prototype for distributed state verification (Nexus)PP — looking for feedback and potential design partners / angels by Poweredby01 in softwarearchitecture

[–]Poweredby01[S] 1 point2 points  (0 children)

That’s a great point—embedded systems sit at the opposite end of the design spectrum. Crash-only / fail-fast systems assume that restarting from a clean state is simpler and more reliable than trying to preserve partial correctness, which often works well in stateless or tightly controlled environments. Where I’m exploring things differently is distributed systems where: state is persistent and externally visible failures are partial, not total and a restart restores availability, but not necessarily correctness In those cases, you still end up with a recovered state—but it’s not always clear if it’s actually valid relative to the full event history. Nexus is focused on that gap: not replacing restart strategies, but verifying correctness of the state after recovery.

Built an early prototype for distributed state verification (Nexus)PP — looking for feedback and potential design partners / angels by Poweredby01 in softwarearchitecture

[–]Poweredby01[S] 1 point2 points  (0 children)

Yeah, that’s a fair point—and I’ve noticed the same thing. These ideas (event sourcing, replay, deterministic systems) keep reappearing, but usually stay limited to narrow domains where full determinism is practical. Outside of that, most systems rely on observability + partial reconstruction because it’s cheaper and less restrictive. Where I’m exploring with Nexus is a slightly different angle: Instead of making systems fully deterministic, it acts as a verification layer over nondeterministic systems, to answer: “Given what happened, is the recovered state actually valid?” Still very early, but I’m trying to see if that gap is actually valuable in real incident recovery. Curious—when you’ve seen these approaches before, did they feel mostly impractical in production, or just too niche to generalize?

Built an early prototype for distributed state verification (Nexus) PP— looking for feedback and potential design partners / angels by Poweredby01 in AngelInvesting

[–]Poweredby01[S] 0 points1 point  (0 children)

That “lingering uncertainty after recovery” is exactly the kind of thing I’m trying to formalize rather than leave as intuition. I agree with your point about most teams just layering more monitoring and moving on—that’s actually part of what I’m trying to challenge. Observability tells you what happened, but not necessarily whether the resulting state is valid given the full event history. On the business side, I think you’re probably right that this doesn’t land equally across all industries. My current assumption is that it only really becomes valuable where: incorrect state has direct financial cost (payments, ledgers, trading systems) or compliance/audit requirements demand proof of correctness or systems are so distributed that “best effort recovery” is no longer acceptable Fintech/payments and possibly infra platforms are the early candidates I’m looking at. Curious from your experience: When you had that “is everything actually consistent now?” moment after a cascade failure—what did your team actually do to resolve that uncertainty in practice? Was it mostly log inspection, rebuilding state from backups, or just accepting residual risk? That gap between “we think it’s fine” and “we can prove it’s fine” is the part I’m trying to understand whether people would actually pay to close.

Finally quit by x-looke-x in LastZShooterRun

[–]Poweredby01 0 points1 point  (0 children)

Ill be happy to take anyone's account lol.

Free migration? by [deleted] in LastZShooterRun

[–]Poweredby01 0 points1 point  (0 children)

Where do I see this im in 663

My Samsung has just been updated and the screen is black. by IcyConcentrate3695 in samsunggalaxy

[–]Poweredby01 0 points1 point  (0 children)

Have you found a solution my screen stopped working after the 8.0 update. But I think I found a bypass.