# realtime Real-time computing performs computations during the corresponding physical process so results can guide it, with correctness required at the correct time. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Logarithmic auto-scaling for Laravel Horizon DevFeed: [Logarithmic auto-scaling for Laravel Horizon]() Original publisher: [Read original article]() Author: Freek Van der Herten (freek@spatie.be) Published: 2026-09-12T12:30:30Z Content type: article Language: en Sources: [freek.dev - all blogposts]() Topics: [Laravel](), [realtime](), [Development]() Tags: [horizon](), [laravel](), [performance](), [queues](), [realtime](), [scaling]() ### AI overview This article explains how logarithmic auto-scaling can be added to Laravel Horizon. Log-based weighting helps prevent large queue spikes from starving smaller realtime queues while still allocating enough workers to large backlogs. ### Source excerpt A thoughtful write-up on adding logarithmic auto-scaling to Laravel Horizon. It shows how log-based weighting keeps huge queue spikes from starving smaller realtime queues while still giving large backlogs enough workers. Read more ## How Yandex combined image and document text signals for image-search ranking DevFeed: [How Yandex combined image and document text signals for image-search ranking]() Original publisher: [Read original article]() Author: nikolaevkona (Яндекс) Published: 2026-08-10T08:00:19Z Content type: tutorial Language: ru Sources: [Яндекс - Как мы делаем Яндекс / Статьи]() Topics: [яндекс](), [vlm](), [Image](), [realtime]() Tags: [image](), [machine-learning](), [ml](), [realtime](), [tag-4004cf5948d3](), [tag-8be2dbf54d97](), [vlm](), [yandex-e983188bc433]() ### AI overview Yandex describes using multimodal vision-language models to jointly assess an image and its associated document text for image-search ranking. The team distilled a larger model into lighter models for different pipeline stages and reports deployment in real-time search. ### Source excerpt Исторически в Яндекс Картинках релевантность документа оценивалась по двум сигналам: насколько запросу подходит само изображение и насколько -- текст, связанный с этим изображением. Такой подход позволяет учесть контент картинки и не провалиться на визуально трудноотличимых объектах, однако он же порождает проблему: в "серой зоне", когда текстовая релевантность не сонаправлена с картиночной, становится неочевидно, как именно агрегировать сигналы в финальный скор релевантности. Привет! Я Константин Николаев, занимаюсь внедрением нейротехнологий в Поиске по картинкам. В этой статье я расскажу, как наша команда научила модели смотреть на картинку и читать текст документа одновременно: начали с тяжёлой мультимодальной VLM ради максимального качества, а затем дистиллировали её в набор лёгких моделей -- по одной под каждую стадию пайплайна. Что из этого удалось довести до realtime-поиска с десятками тысяч запросов в секунду и как совместный анализ двух модальностей добавил 5% релевантных картинок в топ выдачи -- под катом. Читать далее ## Shipping an L1 zkEVM #1: Realtime Proving DevFeed: [Shipping an L1 zkEVM #1: Realtime Proving]() Original publisher: [Read original article]() Author: Sophia Gold Published: 2025-07-10T00:00:00Z Content type: article Language: en Sources: [Ethereum Foundation Blog]() Topics: [Ethereum](), [realtime](), [Formal verification]() Tags: [ethereum](), [formal-verification](), [realtime](), [research-development](), [security]() ### AI overview Ethereum proposes a phased path toward an L1 zkEVM in which validators can verify multiple zkVM-generated execution proofs instead of re-executing execution payloads. The proposal defines realtime-proving targets for zkVM teams and anticipates gradual validator adoption as production security is demonstrated. ### Source excerpt Thanks to Kevaundray Wedderburn, Alex Stokes, Tim Beiko, Mary Maller, Alexander Hicks, George Kadianakis, Dankrad Feist, and Justin Drake for feedback and review. Ethereum is going all in on ZK. Eventually we expect to migrate to using ZK proofs at all levels of the stack, from consensus layer signature... ## Rock and Rollback: Realtime multiplayer in the browser, with rust and bevy DevFeed: [Rock and Rollback: Realtime multiplayer in the browser, with rust and bevy]() Original publisher: [Read original article]() Author: {"image"=\>"rj-headshot.jpg", "greetings"=\>nil} Published: 2024-12-08T06:00:00Z Content type: tutorial Language: en Sources: [Richard Jones]() Topics: [browser](), [browser-game](), [realtime](), [Bevy](), [Rust](), [QUIC](), [WebRTC](), [HTTP](), [Streaming]() Tags: [bevy](), [bevygap](), [browser](), [gamedev](), [http-3](), [multiplayer](), [netcode](), [quic](), [realtime](), [rust](), [snapshots](), [udp](), [webrtc]() ### AI overview This article discusses building a realtime multiplayer browser game with Rust and Bevy. It explains why TCP can delay updates, considers WebRTC and WebTransport over HTTP/3 and QUIC for unreliable data channels, and introduces snapshot interpolation as a multiplayer networking model. ### Source excerpt How hard it is to build a realtime multiplayer browser game? Like asteroids, but multiplayer. Retro vibes with modern netcode 🚀. ## Design an Ad Click Aggregator DevFeed: [Design an Ad Click Aggregator]() Original publisher: [Read original article]() Author: Evan King Published: 2024-12-04T04:20:50Z Content type: tutorial Language: en Sources: [Evan King]() Topics: [data-processing](), [Requirements](), [Latency](), [realtime](), [Database]() Tags: [architecture](), [data-processing](), [database](), [latency](), [performance](), [query](), [realtime](), [requirements](), [scale]() ### AI overview A tutorial on designing an ad click aggregator. It defines functional and non-functional requirements, including advertiser metric queries, scalability, low-latency analytics, fault-tolerant and accurate collection, near-real-time availability, and idempotent click tracking. ### Source excerpt By a former Meta Staff engineer and Co-founder of hellointerview.comFinal DesignUnderstanding the Problem🖱 What is an Ad Click Aggregator An Ad Click Aggregator is a system that collects and aggregates data on ad clicks. It is used by advertisers to track the performance of their ads and optimize their campaigns. For our purposes, we will assume these are ads displayed on a website or app, like Facebook.Functional Requirements Core Requirements Users can click on an ad and be redirected to the advertiser's website Advertisers can query ad click metrics over time with a minimum granularity of 1 minute Below the line (out of scope): Ad targeting Ad serving Cross device tracking Integration with offline marketing channels Non-Functional Requirements Before we jump into our non-functional requirements, it's important to ask your interviewer about the scale of the system. For this design in particular, the scale will have a large impact on the database design and the overall architecture. We are going to design for a system that has 10M active ads and a peak of 10k clicks per second. The total number of clicks per day will be around 100M. With that in mind, let's document the non-functional requirements: Core Requirements Scalable to support a peak of 10k clicks per second Low latency analytics queries for advertisers (sub-second response time) Fault tolerant and accurate data collection. We should not lose any click data. As realtime as possible. Advertisers should be able to query data as soon as possible after the click. Idempotent click tracking. We should not count the same click multiple times. Below the line (out of scope): Fraud or spam detection Demographic and geo profiling of users Conversion tracking Here's how it might look on your whiteboard: The Set UpPlanning the Approach For this question, which is less of a user-facing product and more focused on data processing, we're going to follow the delivery framework outlined here, focusing on the system interfa ## Improved Galileo Time to First Fix DevFeed: [Improved Galileo Time to First Fix]() Original publisher: [Read original article]() Published: 2022-09-07T10:47:39Z Content type: article Language: en Sources: [Bert Hubert's writings]() Topics: [navigation](), [realtime](), [Resilience](), [communications]() Tags: [cloud](), [communications](), [devices](), [gnss](), [gps](), [navigation](), [realtime](), [resilience]() ### AI overview This article explains how new Galileo features can help supported devices obtain a position and time fix faster and more robustly. The features are especially useful for unconnected devices, can improve resilience during communication disruptions, and may speed time synchronization on connected devices. ### Source excerpt In the world of Global Navigation Satellite Systems (GNSS), change tends to happen very slowly and cautiously. It is therefore quite exciting how many new features Galileo, the "European GPS" has been rolling out lately. Earlier I wrote a little bit about the High Accuracy Service (HAS), whereby the Galileo satellites themselves provide properly equipped receivers (not your phone) with near-realtime updates that can be used to achieve very good accuracy. ## Dutch Solar Power Figures Are Estimates Based on the Entrance Model DevFeed: [Dutch Solar Power Figures Are Estimates Based on the Entrance Model]() Original publisher: [Read original article]() Published: 2022-03-27T08:47:53Z Content type: opinion Language: en Sources: [Bert Hubert's writings]() Topics: [data](), [realtime]() Tags: [data](), [energy](), [generate](), [graphs](), [interface](), [live](), [measurements](), [model](), [solar]() ### AI overview The article examines Dutch electricity data submitted to ENTSO-E and explains that the Netherlands does not report solar generation directly. Reported real-time solar figures appear to be estimates produced by the Entrance model, based on parameters such as solar-field data, temperature, irradiation intensity, and panel orientation. ### Source excerpt As part of my coping mechanisms, I like to make graphs of important things I worry about. Recently with the Russia-inflicted horrors in Ukraine, I've been looking at the torrent of Russian gas being bought by Europe. This turned into a live plot that shows just how much money we are sending to Russia. In that post, I also dwell on how we are using that gas to heat our houses and generate electricity. ## The new Galmon.eu Weekly Galileo Report DevFeed: [The new Galmon.eu Weekly Galileo Report]() Original publisher: [Read original article]() Published: 2020-07-07T09:54:59Z Content type: article Language: en Sources: [Bert Hubert's writings]() Topics: [Monitoring](), [data](), [Open Data](), [realtime]() Tags: [blog-post](), [data](), [gnss](), [gps](), [performance](), [realtime](), [report](), [thread](), [weekly]() ### AI overview The post announces the Galmon.eu unofficial Weekly Galileo Report, a public account of Galileo's performance. It explains that the report uses a worldwide GNSS monitoring platform and open data sources to provide near-real-time visibility into the European navigation system. ### Source excerpt I have a longer story brewing, but in this post I want to briefly announce the "Galmon.eu unofficial Weekly Performance Report". This is a blog post version of an earlier Twitter thread. I'm very proud to present the first full Galmon.eu Weekly Galileo Report! And the good news is: it was a good week with very little to report. The email has just gone out, but you can also find it here. ## Why is my Cloud Firestore query slow? DevFeed: [Why is my Cloud Firestore query slow?]() Original publisher: [Read original article]() Author: Todd Kerpelman Published: 2019-08-08T00:00:00Z Content type: tutorial Language: en Sources: [Firebase Blog]() Topics: [Firestore](), [data](), [realtime]() Tags: [best-practices](), [data](), [firebase](), [firestore](), [realtime](), [tutorials]() ### AI overview This tutorial explains why Cloud Firestore queries can appear slow even when the query itself runs quickly. The main causes discussed are transferring large result sets and documents, with suggested fixes including query limits, smaller documents, and separating secondary details into other collections or subcollections. ### Source excerpt News, tutorials, and updates from the Firebase team. ## Localytics' Process for Responding to Service Incidents DevFeed: [Localytics' Process for Responding to Service Incidents]() Original publisher: [Read original article]() Author: Tony Wieczorek Published: 2016-09-13T18:24:39Z Content type: article Language: en Sources: [Localytics]() Topics: [incident](), [systems](), [Slack](), [realtime]() Tags: [downtime](), [engineering](), [incident](), [pagerduty](), [postmortem](), [realtime](), [slack](), [systems]() ### AI overview Localytics describes its process for responding to service degradations and downtime. The process uses Slack and PagerDuty to coordinate triage, debugging, incident follow-up, postmortems, and communication with company leaders and customers. ### Source excerpt We believe the highest performing engineering teams have a process to identify, triage, fix and learn from service degradations and downtime. At Localytics, we build highly available and scalable systems, and part of the key to our success is learning from failures. One way we foster a learning culture is ## Introducing Protector - a Circuit Breaker for Time Series Databases DevFeed: [Introducing Protector - a Circuit Breaker for Time Series Databases]() Original publisher: [Read original article]() Author: Matthias Endler Published: 2016-02-23T00:00:00Z Content type: article Language: en Sources: [Trivago]() Topics: [Time Series](), [Databases](), [browser](), [Grafana](), [realtime](), [Security]() Tags: [backend](), [browser](), [data](), [databases](), [exceptions](), [grafana](), [metric](), [monitoring](), [open-source](), [realtime](), [security](), [sql](), [time-series](), [tool]() ### AI overview trivago describes Protector, an open-source circuit breaker for time series databases. The tool blocks potentially expensive InfluxDB queries and limits CPU and memory usage to help prevent database, browser, and metrics-backend overload. ### Source excerpt At trivago we store a subset of our realtime metric data in InfluxDB and we are quite impressed by the load it can handle. Despite all the joy, we had to learn some lessons the hard way. It is pretty easy to overload the database or the web browser by executing queries that return too many datapoints. ## WebSockets, caution required! DevFeed: [WebSockets, caution required!]() Original publisher: [Read original article]() Author: Sam Saffron Published: 2015-12-29T23:25:05Z Content type: opinion Language: en Sources: [Sam Saffron]() Topics: [WebSocket](), [realtime](), [Rails](), [web applications](), [HTTP](), [middleware]() Tags: [http](), [middleware](), [rails](), [realtime](), [rest](), [web-applications](), [websockets]() ### AI overview The article cautions that WebSockets are not automatically a clear win for most realtime web applications. It highlights operational and development concerns, including debugging, logging, profiling, rate limiting, database connection exhaustion, and the choice between WebSockets and REST for client-to-server communication. It suggests WebSockets are more appropriate for specialized high-concurrency cases such as managing 10k interactive console sessions. ### Source excerpt When developers hear that WebSockets are going to land in the near future in Rails they get all giddy with excitement. minions.jpg492x219 23.2 KB But your users don't care if you use WebSockets: Users want "delightful realtime web apps". Developers want "delightfully easy to build realtime web apps". Operations want "delightfully easy to deploy, scale and manage realtime web apps". If WebSockets get us there, great, but it is an implementation detail that comes at high cost. Do we really need ultra high performance, full duplex Client-Server communication? WebSockets provides simple APIs to broadcast information to clients and simple APIs to ship information from the clients to the web server. A realtime channel to send information from the server to the client is very welcome. In fact it is a part of HTTP 1.1. However, a brand new API for shipping information to the server from web browsers introduces a new decision point for developers: When a user posts a message on chat, do I make a RESTful call and POST a message or do I bypass REST and use WebSockets? If I use the new backchannel, how do I debug it? How do I log what is going on? How do I profile it? How do I ensure it does not slow down other traffic to my site? Do I also expose this endpoint in a controller action? How do I rate limit this? How do I ensure my background WebSocket thread does not exhaust my db connection limit? If an API allows hundreds of different connections concurrent access to the database, bad stuff will happen. Introducing this backchannel is not a clear win and comes with many caveats. I do not think the majority of web applications need a new backchannel into the web server. On a technical level you would opt for such a construct if you were managing 10k interactive console sessions on the web. You can transport data more efficiently to the server, in that the web server no longer needs to parse HTTP headers, Rails does not need to do a middleware crawl and so on. But the majority of ## Managing stale JavaScript and CSS assets with Discourse's message\_bus DevFeed: [Managing stale JavaScript and CSS assets with Discourse's message\_bus]() Original publisher: [Read original article]() Author: Sam Saffron Published: 2014-01-15T02:55:14Z Content type: article Language: en Sources: [Sam Saffron]() Topics: [JavaScript](), [realtime](), [Messaging](), [Rails](), [Ruby](), [Socket.IO](), [Angular](), [Meteor]() Tags: [api](), [javascript](), [json](), [messages](), [rails](), [realtime](), [ruby](), [socket]() ### AI overview The article explains how Discourse addresses stale JavaScript and CSS bundles in single-page applications. It presents the message_bus gem as a mechanism for realtime updates, then describes using an application-version digest and client-side route transitions to refresh assets when versions change. ### Source excerpt The Problem These days all the cool kids are using Ember.JS or Angular or Meteor or some other single page web application. If you deploy often, like we do at Discourse, you have a problem. How can you get everyone to run the latest version of your JavaScript and CSS bundle? Since people do not reload full pages and just navigate around accumulating small json payloads there is a strong possibility people can be on old versions and experience weird and wonderful odd bugs. The message bus One BIG criticism I have heard of Rails and Django lately is the lack of "realtime" support. This is an issue we foresaw over a year ago at Discourse. Traditionally, people add more components to a Rails system to support "realtime" based notifications. Be it Ruby built systems like faye, non Ruby systems like Node.JS with socket.io or outsourced systems like Pusher. For Discourse none of these were an option. We could not afford to complicate the setup process or outsource this stuff to a third party. I built the message_bus gem to provide us with an engine for realtime updates: github.com GitHub - discourse/message_bus: A reliable and robust messaging bus for Ruby and... A reliable and robust messaging bus for Ruby and Rack At the core of it message_bus allows you a very simple API to publish and subscribe to messages on the client: # in ruby MessageBus.publish('/my_channel', 'hello') Behind this trivial API hides a fairly huge amount of feature goodness: This thing scales really well, clients "pull" information from a reliable pub sub channel, minimal per-client house keeping. Built in security (send messages to user or groups only) Built on rack hijack and thin async, so we support passenger, thin, unicorn and puma. Uses long polling, with an event machine event loop, can easily service thousands of clients fro ## Realtime Conf 2013: Favorite talks DevFeed: [Realtime Conf 2013: Favorite talks]() Original publisher: [Read original article]() Author: Graham King Published: 2013-10-22T04:33:21Z Content type: opinion Language: en Sources: [Graham King]() Topics: [realtime](), [WebRTC](), [HTTP](), [Node.js](), [Open Source](), [XMPP](), [Firefox](), [Chrome]() Tags: [chrome](), [conference](), [conferences](), [firefox](), [http](), [node-js](), [open-source](), [realtime](), [software](), [webrtc](), [xmpp]() ### AI overview A personal review of Realtime Conf 2013 in Portland highlights three favorite talks: Isaac Schlueter on leadership and open source, Ilya Grigorik on real-time HTTP with HTTP/2, and Eric Rescorla on WebRTC. It also praises the conference's unusual production and the generosity of its participants. ### Source excerpt Realtime Conf 2013: Where innovation meets whimsy in the world of tech conferences. ## Proxy socket.io and nginx on the same port, over SSL DevFeed: [Proxy socket.io and nginx on the same port, over SSL]() Original publisher: [Read original article]() Author: Graham King Published: 2011-12-22T22:32:26Z Content type: tutorial Language: en Sources: [Graham King]() Topics: [Socket.IO](), [nginx](), [proxy](), [SSL](), [realtime](), [Web](), [Django](), [backends]() Tags: [django](), [haproxy](), [http](), [nginx](), [proxy](), [realtime](), [server](), [socket](), [software](), [ssl]() ### AI overview A tutorial for running Socket.IO realtime traffic and a Django web application on the same SSL port. It uses stunnel to terminate SSL, HAProxy to route WebSocket traffic to Node.js and web traffic to nginx, and nginx with Gunicorn to serve the Django application. ### Source excerpt Streamline your SSL setup: Realtime and web on one port.