aioff.
中文
Product design
PRODUCT DESIGN·8 min

Querri: give recurring data questions a definition you can check

Querri is an AI data analysis tool for operations and analytics teams. It prepares files and connected data, saves common calculations as reusable tables, and helps a team answer business questions using shared definitions.

Break down the problem and try your own design and implementation first. Then explore the reasoning to check states, edge cases, trade-offs, and ways to test your approach. The guide offers a reasoning path, not a complete implementation.

01
CODE EXERCISEAdvanced

Publish a consistent generation of dependent tables

Design a simplified derived-table scheduler. This engineering exercise draws on the article’s mechanism; it does not describe Querri’s implementation. Source table S produces matching table A, and A produces summary table B. Call each sync a generation, identified by an increasing integer g. A and B in a generation must use S from that same generation.

Generation 1 is initially complete and published. Generations 2 and 3 then arrive. Tasks may report completion more than once, finish out of order, or fail.

  1. Define input events, task states, and the published state visible to readers. Readers may see only a complete A/B pair from one generation. A late task from an old generation must not replace a newer one.
  2. Trace this order: A2 succeeds and B2 starts; A3 and B3 succeed; B2 succeeds last. At each step, state whether publication is allowed and which generation readers see.
  3. Explain source-sync failure, A failure, duplicate completion events, successful empty tables, and process restart. An empty table is a valid result, not a failure.
  4. Deliver a state-transition diagram, key invariants, and an executable test checklist. Full implementation code is not required.
Explore the reasoning

  1. Separate calculation completion from reader visibility. Bind each task to at least a View, generation, and input version: A3 depends only on S3, and B3 only on A3. Until a generation is complete, readers retain the last complete published generation and can inspect its time.

  2. In the given sequence, A2 alone cannot switch the whole group. Generation 3 can be published only after both A3 and B3 succeed; late B2 cannot move publication back from 3 to 2. If 2 completes while 3 is still incomplete, publishing 2 and later 3 is allowed. Require the published generation to increase monotonically and switch the group’s visible version as one operation.

  3. Deduplicate completion events by task identity. Distinguish retry attempts, so a late report from an invalid attempt cannot change the current attempt. Failed source syncs do not start the downstream chain; failed A does not start B. Successful empty input yields a valid empty table and must remain distinct from failure.

  4. Persist task results and the published generation for restart, reconcile them, then schedule further work. Interrupt tests after results are written but before the publication pointer changes, and after the pointer changes but before acknowledgment. Replaying must neither lower the generation nor publish twice. Discuss the latency cost of waiting for a complete group. Strict same-generation reads are this exercise’s requirement, not a vendor guarantee.

02
FRONTEND EXERCISEAdvanced

Approve the same rule version that the preview shows

You are building a rule-confirmation panel. A user edits the definition of paid-order value. The service returns a preview containing a request ID, rule version, excluded records, and total. Preview request A is sent first; after an edit, B is sent. The network may return B before A.

  1. Design editing, loading, ready, error, and submitting states. Explain whether approval is allowed in each.
  2. Trace “B returns 140 yuan, then A returns 160 yuan.” Which rule version must the screen and approval request carry? What happens when a response arrives after another edit or after the panel closes?
  3. Approval also carries a version, and the service rejects stale versions. Design conflict handling, failure retry, and keyboard-focus restoration.
  4. Deliver a state diagram, visible messages, and an interaction-test checklist. No implementation is required. Do not present this panel as Querri’s existing interface.
Explore the reasoning

  1. Treat the editable draft, last valid preview, and approved result as distinct objects. Store request identity and rule version when requesting a preview. Accept only the latest request that still corresponds to the current draft. Once B is active, late A must not overwrite 140 yuan. After another edit, an old preview may remain as a reference only if clearly marked stale, with approval disabled.

  2. On approval, freeze the valid version and enter submitting to prevent repeated clicks. Send the rule version and preview identity; client checks do not replace server-side version checks. If the service rejects a stale version, keep the draft, explain why, obtain a fresh preview, and ask the user to confirm again. Never automatically approve the new content.

  3. Test edits during loading, responses after closure, network failure and retry, repeated clicks, and conflict responses. A closed panel must not be updated. Cancellation can reduce work, but correctness still relies on identity checks. Errors should be announced to assistive technology; closing should return focus to the control that opened the panel. Use a keyboard to complete both a successful path and a conflict path.