Find your starting point

1 OF 12 · Your short link goes viral

Can more application replicas remove an unchanged database bottleneck?

No — that conclusion needs a different mechanism or evidence Yes — the component alone proves it I'm unsure

2 OF 12 · Give a burst a budget

Does admission control increase the service capacity of the database?

No — that conclusion needs a different mechanism or evidence Yes — the component alone proves it I'm unsure

3 OF 12 · Defend a link service

Does a successful redirect read trace establish identifier uniqueness and write correctness?

No — that conclusion needs a different mechanism or evidence Yes — the component alone proves it I'm unsure

4 OF 12 · Move a shard, not every key

Why are key counts alone insufficient for estimating partition work?

Different keys can receive very different request volumes Every key always receives exactly the same work I'm unsure

5 OF 12 · Where did my update go?

What does asynchronous replication permit before a change is applied remotely?

A remote read can see an older version Every read must see the change immediately I'm unsure

6 OF 12 · Give every event an identity

Two requests observe the same millisecond timestamp. What is missing from a timestamp-only uniqueness argument?

A safe distinguishing namespace/sequence or coordinated allocation Nothing: timestamps alone are always unique I'm unsure

7 OF 12 · A worker crashes after the side effect

Does at-least-once delivery by itself guarantee exactly one external side effect?

No: application effects need their own correctness argument Yes: delivery policy automatically makes effects atomic I'm unsure

8 OF 12 · Deliver with evidence, not optimism

What does placing a notification in a queue prove about recipient delivery?

Only that this stage accepted the work under its contract That the recipient has read it I'm unsure

9 OF 12 · A celebrity changes the workload

If a post has many more followers, what happens to eager per-follower materialization work?

More follower updates must be considered The amount of work is independent of followers I'm unsure

10 OF 12 · Reconnect without losing the story

Does in-order delivery prove that all messages sent during a disconnect will arrive?

No: ordering and arrival guarantees are different Yes: ordering automatically provides durable replay I'm unsure

11 OF 12 · Did the payment happen?

After an uncertain timeout, which observation is sufficient to declare no side effect happened?

The timeout alone is insufficient; provider evidence is needed The timeout itself proves absence I'm unsure

12 OF 12 · Diagnose an unfamiliar outage

Can a throughput drop alone distinguish a traffic burst from a slower dependency?

No: correlate offered work, service and queue evidence Yes: throughput identifies the cause by itself I'm unsure

What would you question first?

Can more application replicas remove an unchanged database bottleneck?

Does admission control increase the service capacity of the database?

Does a successful redirect read trace establish identifier uniqueness and write correctness?

Why are key counts alone insufficient for estimating partition work?

What does asynchronous replication permit before a change is applied remotely?

Two requests observe the same millisecond timestamp. What is missing from a timestamp-only uniqueness argument?

Does at-least-once delivery by itself guarantee exactly one external side effect?

What does placing a notification in a queue prove about recipient delivery?

If a post has many more followers, what happens to eager per-follower materialization work?

Does in-order delivery prove that all messages sent during a disconnect will arrive?

After an uncertain timeout, which observation is sufficient to declare no side effect happened?

Can a throughput drop alone distinguish a traffic burst from a slower dependency?