Design Notes on Bilibili Trace

Bilibili Trace came from a small frustration: video numbers move over time, but most pages show them as if the current value is the whole story.

For a creator or an observer, the interesting part is often the change. A video reaching a target, slowing down, getting new comments, or moving differently from another video is more useful than a single static count.

1. Treat Metrics as Time, Not Labels

Likes, comments, coins, and views are usually presented as labels on a page. That is enough for casual reading, but not enough for tracking.

The design idea is to treat each metric as something that changes over time. Once the data is time-based, the product can answer better questions:

• Is this video still moving?
• Did it pass the target?
• Which metric changed first?
• Is the change normal or unusual?
• Which tracked videos need attention?

That changes the product from a table of numbers into a monitoring surface.

2. Keep the First Version Operational

It is tempting to start with charts, predictions, notification rules, and dashboards. Those can be useful later, but they are not the foundation.

The first useful loop is smaller:

add a video -> store its metrics -> compare current values -> make the change visible

If that loop is reliable, analysis features have something to stand on. If that loop is weak, better charts only make unreliable data look more polished.

3. Design Around Targets

Targets make raw metrics easier to understand.

A number like 923 does not say much by itself. But 923 / 1000 immediately creates context. It tells me how far the video is from a goal and whether the next refresh matters.

That is why target comparison belongs near the core of the product. It gives the tracking page a simple reason to exist: not just “what is the number now”, but “how close is it to the thing I care about”.

4. Keep Data Access Boring

For this project, boring backend choices are a feature.

Spring Boot, MySQL, MyBatis-Plus, and a clear controller-service-entity structure make the system easier to inspect. The point is not to invent a clever architecture. The point is to make metric collection, storage, and display predictable.

I also like avoiding hand-written SQL for normal queries when a structured query wrapper is enough. It keeps common reads consistent and reduces small mistakes in a project where the data model matters more than query cleverness.

5. Leave Room for Accounts Without Requiring Them First

User accounts, subscriptions, and notification rules are natural future features. But they should not be required for the earliest version to be useful.

The early product can still track a shared set of videos and prove that the data loop works. Once that is stable, accounts become a way to personalize tracking instead of a prerequisite for basic value.

Current Rule

For Bilibili Trace, the design rule is:

make changing numbers easier to notice

The project should stay focused on turning scattered video metrics into a small, readable monitoring workflow.