Difference between revisions of "Realtime"
| Line 1: | Line 1: | ||
| − | [[Realtime]] (alternatively spelled, [[real-time]]) is a [[concept]] of quick adjusting of all the parts of one [[system]] to a change in one part. Because ''quick'' still has some lag, the [[near real-time]] and [[nearly real-time]] terms are also used. The unavoidable lag is known as a [[real-time constraint]]. | + | [[Realtime]] (alternatively spelled, [[real-time]]) is a [[concept]] of quick adjusting of all the parts of one [[system]] to a change in one part. Because ''quick'' still always has some lag, the [[near real-time]] and [[nearly real-time]] terms are also used. The unavoidable lag is known as a [[real-time constraint]]. |
Revision as of 17:59, 8 February 2020
Realtime (alternatively spelled, real-time) is a concept of quick adjusting of all the parts of one system to a change in one part. Because quick still always has some lag, the near real-time and nearly real-time terms are also used. The unavoidable lag is known as a real-time constraint.
Realtime data, apps, and the ecosystem around them is growing exponentially. But we still can’t agree on how we describe the APIs powering this realtime growth. The problem is that there are various ways to describe APIs that provide realtime functionality. Event-driven seems to be the most common descriptor. Gartner has adopted the term, stating that by 2020 50% of all managed APIs will be event-driven. But still today there is no consistency or consensus between what terms like realtime API, event-driven API, or streaming API refer to. Often they’re used interchangeably.
As an engineering team and API provider working on a global pub/sub messaging platform, we work with these ideas everyday. We’ve watched discussions around event-driven architecture, webhooks, and streaming data proliferate. Over the years we’ve thought extensively about the best terminology to use and arrived at what we call the Realtime API Family.
