A time series is the same measurement taken repeatedly on a fixed cadence. One follower count is a fact about an instant. A hundred of them, one per hour, is a fact about a direction.
Almost every question people ask a social API is actually the second kind.
Now against rising
| Question | Needs | Can an API answer it on demand? |
|---|---|---|
| How many followers does this account have? | One read | Yes |
| What is trending right now? | One read of a ranking | Yes |
| Is this growing? | Many reads over time | Only if somebody stored them |
| What is already dying? | Same | Same |
This is the part that cannot be bought retroactively. A live API, however fast, cannot tell you what a number was last Tuesday if nobody wrote it down on Tuesday. History is not a feature you add later — it is a decision somebody made before you asked.
What makes a series usable
- A fixed cadence. Hourly means every hour. A window collected at 14:03 and the next at 19:40 are not comparable points.
- Gaps recorded as gaps. A missing hour must be visible as missing, not interpolated and not dropped. Otherwise a collection outage reads as a flat week.
- A stable identity. If the thing you are tracking can be renamed, anchor on the identifier and not the name, or your series silently splits in two — see anchor field.
- Empty distinguished from failed. A source that returned nothing this hour is not the same as a source that broke. We keep those in separate columns for exactly this reason, per source under sources.
Cost, which is the quiet advantage
A time series is cheap to read and expensive to have. Asking "what changed" costs one query against stored data; reconstructing it from a live API costs one read per point per entity, forever, and under per-resource pricing that is the bill that surprises people.
Our archive holds hourly windows across public sources since it opened, and the archive page is where that is published. The trend routes read from it rather than from a live fetch, which is why they answer a question a firehose cannot.