Three questions from my Lalamove interview — on data freshness, metric accuracy, and why the data mart is your most important product. Written for both engineers and the executives who depend on their work.
Data infrastructure fails in three predictable ways: dashboards go stale, metrics report the wrong number, and nobody trusts the data enough to act on it. These are the three questions I was asked — and my answers come back to one idea: the data mart is a product, not plumbing.
Decisions made on stale data cost more than the engineering to prevent it.
Stale data occurs when a dashboard shows you a number from hours or days ago but makes it appear current. The risk isn't just inconvenience. It's those decisions that get made on outdated reality.
The fix is incremental updates: instead of rewriting the entire dataset every hour, we only process what's new. Think of it like syncing new emails instead of downloading your entire inbox from scratch every time you open Outlook. Faster, cheaper, and if something goes wrong, easy to reprocess just the broken window.
Insight: Hourly updates catch most data problems before they reach a dashboard at a fraction of the cost of a real-time system. For executive reporting, that's usually the right trade-off.
| What we monitor | What triggers an alert | Why it matters |
|---|---|---|
| Data volume | Drops more than 20% vs normal | Means something upstream broke |
| Data age | More than 90 min since last update | Means the pipeline stalled |
| Data consistency | Key fields are missing or duplicated | Means reports will be wrong |
The wrong aggregation shows leadership a number that's 3× too high. Silently.
| Metric type | Plain-English rule | Lalamove example |
|---|---|---|
| Can be added up | Add across any time period or region | Total orders, total revenue, total km driven |
| Can only be added some ways | Add across regions — but NOT across time periods | Drivers logged in today (Tuesday's count + Monday's count ≠ this week's count) |
| Must be recalculated fresh | Never add — always recalculate from scratch for the time window you need | % of on-time deliveries, average order value, customer satisfaction score |
Most BI tools will happily add up any number you give them. The problem is that some numbers, like the count of active drivers or your on-time delivery rate, don't work that way. Add them up across days, and you get a number that's plausible but wrong. The fix is to calculate these metrics fresh for each time window (daily, weekly, monthly) rather than letting the dashboard sum them automatically.
Insight: A driver who works Monday, Wednesday, and Friday counts once in the weekly report but three times if you sum the daily reports. That gap between what the system reports and what actually happened is where trust in data breaks down.
A data mart is only valuable if people trust it enough to use it.
Most data teams build for engineers. I build for the people who open the dashboard at 8am and need to make a decision by 9am.
| If data is just plumbing… | If data is a product… |
|---|---|
| It works until it breaks, then someone scrambles | It has an SLA — if it's late, the right person is already fixing it |
| Column names are for engineers | Column names are readable by anyone |
| Changes ship whenever they're ready | Changes come with a migration window so nothing downstream breaks |
| Success = it runs | Success = people use it and trust it |
When I call the data mart the product, I mean: the analyst who opens it at 8 am is my user. Their needs define what I build, not the technical elegance of the pipeline behind it.
In practice, that means three things:
First, it has to be reliable. Not 'usually works' reliable — SLA reliable. If the dashboard is late, someone is already on it before the user notices.
Second, it has to be understandable. A metric called 'completed_order_count' tells a PM something. A metric called 'cnt_co' tells them nothing. Documentation ships with the data, not six months later.
Third, it has to be trustworthy over time. When we change something, we give users time to adapt. No surprise schema changes that break their reports on a Monday morning.
Insight: A mart nobody queries is just expensive storage. Adoption and trust are the real success metrics, not whether the pipeline ran on time.