В традиционных базах данных данные всегда имеются в наличии до того, как к ним адресуются запросы, но в системах реального времени, в которых данные никогда не сохраняются, инфраструктура должна обеспечить управление данными, которые запаздывают или задерживаются, отсутствуют или поступают не в ожидаемом порядке.
В связи с этим одно из требований состоит в возможности установки тайм-аутов для индивидуальных вычислений. Например, рассмотрим простое бизнес-аналитическое приложение реального времени, которое вычисляет среднюю стоимость после последнего изменения цены для набора из 25 ценных бумаг. Требуется дождаться изменения цены каждой ценной бумаги и потом выдать среднюю стоимость. Однако предположим, что одна из ценных бумаг продается плохо, и ее стоимость не изменяется в течение следующих 10 минут. Это пример вычисления, которое должно блокироваться в ожидании входных данных, требуемых для его завершения. Такие входные данные могут своевременно поступить, а могут и не поступить. В действительности, если SEC (Security Exchange Commission - Комиссия по ценным бумагам) предпишет остановить торги для одной из ценных бумаг, то вычисление будет заблокировано навсегда. В системе реального времени допущение бесконечной блокировки программы никогда не является хорошей идеей. Поэтому любому вычислению, которое может блокироваться, должно быть разрешено устанавливать контрольный интервал времени, тайм-аут, после истечения которого вычисление будет возобновлено над частично доступными данными. В любой системе обработки данных реального времени должны иметься такие тайм-ауты для любой потенциально блокируемой операции.
Аналогичные проблемы возникают в связи с нарушением порядка данных. Обычно окно, определенное на основе времени, (например, [9:00 - 9:01]) должно закрываться при поступлении первого сообщения, значение временной метки которого больше значения верхней границы окна. Однако такое действие основывается на предположении, что данные поступают в порядке своих временных меток, что может быть и не так в данном случае. Для работы с данными, нарушающими порядок, должен обеспечиваться механизм, позволяющий окнам оставаться открытыми в течение дополнительного периода времени. Одно из решений этой проблемы, представленное в Aurora, основывается на понятии резерва времени (slack) [].
Третье требование состоит в том, что должны иметься встроенные механизмы, обеспечивающие устойчивость к "дефектам" потоков, включая отсутствие и нарушение порядка данных, что обычно присутствует в реальных потоках данных.