Torben — Senior Backend Engineer in Hamburg. Resilient distributed systems in .NET and Rust, and Tipperoo, an ad-free football prediction game. Zola 2026-07-16T00:00:00+00:00 https://www.torbenlabs.com/atom.xml 2026-07-16T00:00:00+00:00 2026-07-16T00:00:00+00:00 Torben https://www.torbenlabs.com/posts/never-score-on-unreconciled-data/ <p>I’m building <a href="https://www.torbenlabs.com/projects/tipperoo/">Tipperoo</a>, an ad-free football prediction game, and I want to write about the part that surprised me.</p> <p>I assumed the interesting work would be the scoring. It isn’t. Scoring is a pure function: you have a tip, you have a result, you produce points. You can write it in an afternoon and unit test it into the ground.</p> <p>The hard part is the sentence just before that: <em>you have a result</em>.</p> <h2 id="a-result-is-a-claim-not-a-fact"><a class="zola-anchor" href="#a-result-is-a-claim-not-a-fact" aria-label="Anchor link for: a-result-is-a-claim-not-a-fact">A result is a claim, not a fact</a></h2> <p>When a match ends 2:1, that number arrives from a data provider over HTTP. It feels like a fact. It is not. It’s a claim, and claims have a lifecycle:</p> <ul> <li>The match is still live, so the score is true <em>right now</em> but not final.</li> <li>The match ended 90 minutes ago and the provider still says 2:1, which probably means it’s final — or it means nobody’s updated it.</li> <li>The match went to extra time, and “full time” means something different.</li> <li>The result gets <strong>corrected</strong> an hour later, because an own goal was reattributed.</li> <li>The fixture was <strong>postponed</strong>, after people had already tipped it.</li> </ul> <p>If you treat the first number you see as truth, every one of those turns into a user-visible lie. And in a prediction game, a wrong table isn’t a cosmetic bug. The entire product is a promise that the standings are right. Get that wrong once in front of someone’s colleagues and there’s no reason to come back.</p> <p>So the rule I’ve been building around: <strong>never score on unreconciled data.</strong></p> <h2 id="what-that-looks-like-in-practice"><a class="zola-anchor" href="#what-that-looks-like-in-practice" aria-label="Anchor link for: what-that-looks-like-in-practice">What that looks like in practice</a></h2> <p>Three things, none of them clever, all of them annoying to skip.</p> <p><strong>Results have explicit states.</strong> A result is <code>provisional</code> until two independent sources agree, and only then <code>confirmed</code>. Points computed from provisional data are <em>shown</em> as provisional — visibly, with a label. Not greyed out and hoped about. The UI is allowed to say “we don’t know yet”. It is not allowed to render a confirmed-looking number over data that might move.</p> <p>That distinction sounds obvious written down. It’s very easy to lose, because the cheapest thing to build is a single <code>score</code> column that just gets <code>UPDATE</code>d, and the difference between “provisional 2:1” and “confirmed 2:1” is invisible in that model right up until it matters.</p> <p><strong>Results are an append-only log.</strong> A correction is a new event, not an update. The standings are derived from the log, so fixing a result recomputes the table instead of silently rewriting it — and I can answer “why did my points change?” with something better than a shrug. This costs almost nothing to do on day one and is genuinely painful to retrofit.</p> <p><strong>Live push carries no data.</strong> This is the one I changed my mind about. The obvious design is to push the new score to the browser over a socket. It works, and it’s fast, and it means the score on screen is now a claim your transport layer is responsible for keeping true forever. Every dropped, duplicated or out-of-order message becomes a wrong number in front of a user.</p> <p>So instead the database emits an <em>opaque</em> signal — transactionally, as part of the same write — and the client refetches the durable row. The signal carries no score. It says only: something you care about changed, go look. A lost message costs a refetch. It can’t cost correctness, because the message never contained the truth in the first place.</p> <p>That’s a worse design on a latency benchmark and a much better one at 5pm on a Saturday.</p> <h2 id="the-actual-lesson"><a class="zola-anchor" href="#the-actual-lesson" aria-label="Anchor link for: the-actual-lesson">The actual lesson</a></h2> <p>None of this is novel. It’s the same lesson every system with an external source of truth teaches eventually: <strong>the boundary is where correctness goes to die.</strong> The provider is not lying to you, it’s just answering a different question than the one you’re asking. It’s answering “what do I currently believe?” and you’re asking “what happened?”</p> <p>The engineering is mostly in refusing to conflate those two, and in being willing to show a user “not yet” instead of a confident wrong answer.</p> <p>Ask me how well it held up after the first real matchday — the beta rides on 2. Bundesliga in August, and I fully expect reality to find something I haven’t thought of.</p> 2026-07-16T00:00:00+00:00 2026-07-16T00:00:00+00:00 Torben https://www.torbenlabs.com/projects/tipperoo/ <h2 id="why">Why</h2> <p>A <em>Tippspiel</em> is a fixture of German office and family life: everyone predicts the scores, points accumulate, someone’s uncle wins. The category leader is a decade-old site funded by advertising and bookmaker odds. That works, but it means the thing you play with your family is also quietly a funnel into gambling.</p> <p>Tipperoo is the counter-position: no ads, no odds, no entry fees, no operated money — permanently, as a matter of identity rather than a launch promise.</p> <h2 id="what-s-interesting-technically">What’s interesting technically</h2> <p>The hard part isn’t the tipping. It’s being <strong>right</strong>, in public, on a Saturday afternoon when six matches finish at once and everyone is refreshing.</p> <p><strong>Never score on unreconciled data.</strong> A football result arrives from a provider as a number, but it isn’t truth yet — it can be corrected, a match can go to extra time or penalties, a fixture can be postponed after people have already tipped. So results move through explicit <code>provisional → confirmed</code> states, and points are only final once two independent sources agree. The UI has to <em>show</em> that distinction rather than paper over it — provisional points are visibly provisional.</p> <p><strong>Corrections have to be cheap.</strong> Results are an append-only event log. A correction is a new event, not an <code>UPDATE</code>, so the standings recompute from the log and the change is auditable rather than mysterious.</p> <p><strong>Live push that can’t lie.</strong> The tempting design is to push the score to the browser. The problem is that a pushed score is a claim you then have to keep consistent forever. Instead the database emits a transactional, <em>contentless</em> signal, and the client refetches the durable row. A lost or duplicated message costs a refetch — never a wrong number on screen.</p> <p>Most of the interesting work has been in the seams: what counts as truth, how you prove it, and what you show a user while you’re still deciding.</p> <h2 id="status">Status</h2> <p>Not launched. The market page and waitlist are live at <a rel="noopener noreferrer external" target="_blank" href="https://tipperoo.de">tipperoo.de</a>; the soft beta rides on 2. Bundesliga from <strong>7 August 2026</strong>, with general availability targeted for <strong>18 August</strong>, gated on readiness rather than the date. Bundesliga and Premier League for the 2026/27 season, bilingual German and English from day one.</p>