The Dead Velociraptor

GlagalCloud was stable. Customer data was isolated, the priority queue managed demand, and temporary workers handled the peaks. Then Krothva — the most experienced velociraptor, the one who had been with Glagalbagal since the first instruction tablet — ate a bad fish and died.

The sources are vague on the species of fish. It was described as "the spiny one from the eastern river," which narrows it to approximately forty species, several of which are toxic. Krothva, who had survived infinite loops, carrying cascades, and a particularly aggressive goat, was felled by a fish. Life, as Blortz observed, was not fair.

The Half-Finished Job

Krothva had been processing Hjelvran's end-of-quarter inventory analysis — a complex job that involved joining trade records from three warehouses, computing totals by goods type, and comparing against the previous quarter. The job was approximately two-thirds complete. Intermediate results sat in Hjelvran's working baskets: partial sums, temporary indexes, comparison values that had meaning only in the context of the specific step Krothva had reached.

No other velociraptor knew which step Krothva had been on. The instruction tablet for the inventory analysis contained forty-seven steps. Krothva had completed somewhere around step thirty. But there was no record of her progress — she had been keeping track in her head, as all velociraptors did, advancing through the instruction tablet one step at a time.

Blortz: We know she was past step twenty, because the partial sums in the working baskets could only exist after step twenty. But we do not know if she was on step thirty or step thirty-five. The intermediate values are consistent with either.

Glagalbagal: Can we resume from step twenty?

Blortz: We would redo steps twenty through thirty — or thirty-five — and produce duplicate results mixed with the existing intermediates. The working baskets would be corrupted.

Glagalbagal: Can we resume from step one?

Blortz: We can. It means discarding two-thirds of Krothva's work and starting over. The job takes twelve hours. That is eight hours wasted.

Hjelvran, informed of the delay, was displeased. His quarterly report was due to his trading partners in two days. Eight hours of wasted work, plus twelve hours to redo the job, left almost no margin.

The Checkpoint

Glagalbagal could not prevent velociraptors from dying (though he did ban the eastern river fish from the cave premises). What he could prevent was the loss of progress.

He introduced checkpoints — designated steps in any long-running instruction tablet where the velociraptor would pause and record its current state. The checkpoint record included:

The customer code. The instruction tablet identifier. The current step number. A snapshot of all working baskets at that moment.

Checkpoints were placed every ten steps. A velociraptor reaching step 10 would save its state. At step 20, save again (overwriting the previous checkpoint — only the most recent one was needed). At step 30, save again.

If a velociraptor died at step 33, the checkpoint from step 30 existed. A replacement velociraptor could read the checkpoint, load the working basket values from step 30 into the working area, and resume from step 31. Three steps of work lost, not twenty.

Blortz: We are trading a small amount of time at each checkpoint for a large amount of time saved if something fails.

Glagalbagal: How much time does each checkpoint take?

Blortz: About two minutes — writing the step number and copying the working baskets to the checkpoint shelf. For a twelve-hour job with checkpoints every ten steps, the overhead is roughly twenty minutes. The insurance against failure is worth twenty minutes.

The Redundant Worker

Checkpoints reduced the cost of failure but did not eliminate it. Three steps of work were still lost, plus the time to load the checkpoint and assign a new velociraptor. For critical jobs — the chieftain's annual census, Thvajjik's regional tax aggregate — even a small delay was unacceptable.

For these jobs, Glagalbagal introduced redundancy: two velociraptors processing the same job simultaneously, independently, on separate copies of the data. If one died (or made an error, or was called away for an emergency), the other continued without interruption. The result was taken from whichever one finished successfully.

Blortz: You are paying two velociraptors to do the work of one.

Glagalbagal: I am paying for certainty. The chieftain does not accept "our velociraptor ate a bad fish" as an excuse for a late census.

Blortz: And if both velociraptors eat a bad fish?

Glagalbagal: I have banned the fish.

Blortz: You have banned one species of fish. There are others.

The probability of both velociraptors failing on the same job was low but not zero. For truly critical operations, Glagalbagal considered tripling the redundancy — three velociraptors on the same job. But the economics were prohibitive for most tasks. The general policy settled at: routine jobs get checkpoints; critical jobs get checkpoints plus one redundant worker; nothing gets three.

The Gaming Incident

The pricing model — base rate for storage, per-operation for computation — had worked well. Until a customer named Vrothka discovered a loophole.

Vrothka was a grain merchant who stored modest records and ran occasional queries. His monthly bill was low. He realised, however, that the per-operation rate did not distinguish between operations on his own data and operations that generated new data. He submitted a query that was technically valid but operationally absurd: "For each of my forty-two grain records, create a cross-reference with every other grain record and compute the ratio." This generated 42 times 41 = 1,722 ratios, each requiring a multiplication and a division. The result was a massive temporary dataset that consumed working baskets, occupied a velociraptor for six hours, and displaced three other customers' jobs from the priority queue.

Vrothka's intent was to inflate his computation usage and then argue to Thvajjik that his tax liability should be reduced because of his "substantial computational expenses." The argument was creative, legally questionable, and extremely annoying.

Glagalbagal: He used our system to generate meaningless data so he could claim a tax deduction for the cost of generating it.

Blortz: The pricing model incentivised it. Per-operation billing rewards customers who perform many operations, even useless ones, if they can expense them. You need limits.

Glagalbagal added resource quotas — each customer had a maximum number of operations per day and a maximum amount of working basket space. Jobs that exceeded the quota were rejected with an explanation. Customers who needed more could purchase a higher tier.

The quota system ended the gaming, though Vrothka protested vigorously and switched to a competitor — a competitor who, at that time, did not exist, which meant Vrothka simply did his own calculations by hand for three months before quietly re-subscribing.