Real Time Data | Techlist.io

stripeApr 29, 20264 min readCurated summary

Everything we announced at Sessions 2026

Stripe announced 288 products and features at Stripe Sessions, focused on making payments more programmable, expanding the protection offered by its global network, and supporting AI-driven commerce. Major launches cover agentic payments, checkout optimization, fraud prevention, in-person payments, and merchant-of-record services. The overall direction is toward infrastructure that supports automated transactions, global commerce, and new usage-based business models. ## Agentic Commerce and Payments - The Agentic Commerce Suite lets businesses upload product catalogs and control how AI agents access them through the Stripe Dashboard. - Platforms can make connected accounts “agent-ready,” with discovery, checkout, payments, and fraud detection handled through one integration. - Partnerships with Meta and Google enable: - Native checkout inside Facebook ads. - Purchases through Google AI Mode and the Gemini app using the Universal Commerce Protocol. - The Machine Payments Protocol supports agent-driven microtransactions, recurring payments, and other programmatic transactions. - Agents can pay using stablecoins or fiat payment methods, including cards, Klarna, and Affirm, through Shared Payment Tokens and the PaymentIntents API. ## Link and Checkout Improvements - Businesses can authorize agents to pay through Link’s agent wallet while retaining spending controls and purchase visibility. - Link adds Pix and stablecoin support for US businesses, with UPI support in India previewed. - A new Dashboard view shows Link’s effect on conversion, authorization rates, and payment costs. - Checkout Studio will use AI assistance, transaction replay, A/B testing, and recommendations to configure and improve checkouts. - Stripe previewed an embedded Checkout form for interfaces such as sidebars, chat boxes, and modals. - More payment methods now support subscriptions, localized currencies, and cross-border payments, including Pix, UPI, Bizum, BLIK, Pay by Bank, and TWINT. - Adaptive Pricing AI can detect a customer’s preferred currency and localize subscription prices. ## Stripe Terminal and Managed Payments - The Stripe Reader T600 includes an eight-inch screen and can run custom applications for loyalty programs and upselling. - Terminal expands to 15 additional markets and adds payment methods such as Alipay, Klarna, and UnionPay International. - Standalone mode will allow businesses to accept payments without building a point-of-sale system. - Stripe Managed Payments is now available to all digital businesses as a merchant-of-record solution, handling indirect tax compliance in more than 80 countries, fraud, disputes, and customer support. ## Payments Optimization and Intelligence - Businesses can A/B test Authorization Boost against their existing payment performance. - New AI optimizations, including Data Only authentication and PINless debit retries, reportedly increase acceptance rates by an average of 3.8% and reduce processing costs by up to 3.3%. - Stripe 3DS can now be used independently for payments processed by another provider. - The Dashboard assistant can investigate payment performance, identify root causes, and recommend actions using natural language. ## Expanded Fraud Protection with Radar Stripe’s Radar upgrades target newer forms of abuse, including token misuse, account fraud, trial abuse, and fraudulent AI-agent activity. - Free-trial abuse prevention identifies risky trials without unnecessarily blocking legitimate customers. - Radar Signals can detect fraudulent payments, predict disputes and early fraud warnings, identify pay-as-you-go abuse, and detect multi-account or account-sharing behavior. - New merchant signals assess risks such as merchant delinquency and suspicious websites using LLM-powered analysis. - Stripe Issuing authorization signals extend fraud prediction to cards issued by other banks, fintechs, and payment providers. - Radar protection now covers additional payment types, including bank debits, wallets, BNPL, and stablecoins. - Custom Radar models combine a company’s own data with Stripe’s network intelligence. - Improved Checkout interventions use targeted measures such as CAPTCHAs to reduce fraud with less impact on conversion. - Smart Disputes can recommend evidence such as tracking numbers and usage logs, while an evidence library stores reusable documents like terms and conditions. ## Revenue and AI-Native Business Models Stripe also began upgrading its Revenue suite for AI-focused businesses. The announced direction includes real-time metering, rating, alerting, streaming payments, dimensional pricing, new Billing customizations, and broader access to query-ready data. The supplied post ends before detailing these Revenue features. Stripe’s announcements point toward a unified platform for global, automated commerce: businesses can sell through agents, optimize payments with AI, extend fraud controls across payment networks, and support flexible pricing models. Companies building AI products or international digital businesses should evaluate the new agentic commerce, Radar, Checkout, and Managed Payments capabilities as they become available.

Read original

Real Time Data Stripe Agentic Commerce Fraud Detection+4

stripeMar 20, 20262 min readCurated summary

Three of the biggest fraud trends from MRC Vegas 2026

Fraud is becoming more automated, adaptive, and difficult to detect with traditional rules-based systems. At MRC Vegas 2026, leading fraud teams emphasized dynamic authentication, fraud controls embedded directly into agentic payments, and layered identity verification to address deepfakes and synthetic identities. The common goal is to reduce friction for trusted customers while applying stronger defenses where risk is highest. ## Dynamic Authentication Based on User Intent - Universal authentication creates unnecessary friction, increases false positives, and can cause businesses to lose legitimate customers and their long-term value. - Airbnb advocates building behavioral profiles over time to measure “high-trust velocity”—the likelihood that a user’s activity reflects legitimate intent. - Trusted users can proceed without additional challenges, while authentication is reserved for the small percentage of traffic proven to be risky. - Stripe Radar’s adaptive 3DS uses AI to trigger authentication only when transaction behavior appears unusual. - Stripe reports that eligible businesses have seen fraud reductions of more than 30% with this approach. ## Fraud Detection for Agentic Commerce - Ashley Furniture’s existing rules-based system handled different authorization needs for quick-ship products and custom orders. - That model became insufficient when AI agents began making purchases across channels. - Fraud detection must be part of the payment infrastructure and evaluate transactions in real time, rather than analyzing them only after purchase. - Stripe Shared Payment Tokens let agents use a customer’s saved payment method without exposing payment credentials. - Combined with Stripe Radar, these tokens transmit risk signals such as potential disputes, card testing, stolen-card usage, and issuer declines. - These signals help distinguish legitimate, high-intent agents from low-trust automated bots. ## Deepfakes and Synthetic Identity Fraud - Fake identities are easier to create because criminals can access document templates and generative AI impersonation tools. - Fraudsters may produce convincing fake IDs, images, voices, and videos with limited resources. - Effective verification depends on identifying inconsistencies that forgeries fail to reproduce, such as incorrect signatures, mirrored photos, or mismatched expiration dates. - No single verification check is reliable enough; multiple independent checks are necessary. - Stripe Identity uses AI to detect fake documents and spoofed photos, compare ID images with selfies, and validate Social Security numbers and addresses against databases. Businesses should replace blanket controls with risk-sensitive interventions: minimize friction for trusted users, integrate fraud detection into agent-driven payment flows, and use layered identity verification to catch increasingly convincing forgeries.

Read original

Real Time Data Machine Learning Generative AI Stripe+4

netflixNov 14, 2025Original article

How and Why Netflix Built a Real-Time Distributed Graph: Part 1 — Ingesting and Processing Data Streams at Internet Scale | by Netflix Technology Blog | Netflix TechBlog (opens in new tab)

Netflix has developed a Real-Time Distributed Graph (RDG) to unify member interaction data across its expanding business verticals, including streaming, live events, and mobile gaming. By transitioning from siloed microservice data to a graph-based model, the company can perform low-latency, relationship-centric queries that were previously hindered by expensive manual joins and data fragmentation. The resulting system enables Netflix to track user journeys across various devices and platforms in real-time, providing a foundation for deeper personalization and pattern detection. ### Challenges of Data Isolation in Microservices * While Netflix’s microservices architecture facilitates independent scaling and service decomposition, it inherently leads to data isolation where each service manages its own storage. * Data scientists and engineers previously had to "stitch" together disparate data from various databases and the central data warehouse, which was a slow and manual process. * The RDG moves away from table-based models to a relationship-centric model, allowing for efficient "hops" across nodes without the need for complex denormalization. * This flexibility allows the system to adapt to new business entities (like live sports or games) without requiring massive schema re-architectures. ### Real-Time Ingestion and Normalization * The ingestion layer is designed to capture events from diverse upstream sources, including Change Data Capture (CDC) from databases and request/response logs. * Netflix utilizes its internal data pipeline, Keystone, to funnel these high-volume event streams into the processing framework. * The system must handle "Internet scale" data, ensuring that events from millions of members are captured as they happen to maintain an up-to-date view of the graph. ### Stream Processing with Apache Flink * Netflix uses Apache Flink as the core stream processing engine to handle the transformation of raw events into graph entities. * Incoming data undergoes normalization to ensure a standardized format, regardless of which microservice or business vertical the data originated from. * The pipeline performs data enrichment, joining incoming streams with auxiliary metadata to provide a comprehensive context for each interaction. * The final step of the processing layer involves mapping these enriched events into a graph structure of nodes (entities) and edges (relationships), which are then emitted to the system's storage layer. ### Practical Conclusion Organizations operating with a highly decoupled microservices architecture should consider a graph-based ingestion strategy to overcome the limitations of data silos. By leveraging stream processing tools like Apache Flink to build a real-time graph, engineering teams can provide stakeholders with the ability to discover hidden relationships and cross-domain insights that are often lost in traditional data warehouses.

Real Time Data Distributed Systems Microservices Data Architecture+3

netflixOct 21, 2025Original article

Behind the Streams: Real-Time Recommendations for Live Events Part 3 | by Netflix Technology Blog | Netflix TechBlog (opens in new tab)

Netflix manages the massive surge of concurrent users during live events by utilizing a hybrid strategy of prefetching and real-time broadcasting to deliver synchronized recommendations. By decoupling data delivery from the live trigger, the system avoids the "thundering herd" effect that would otherwise overwhelm cloud infrastructure during record-breaking broadcasts. This architecture ensures that millions of global devices receive timely updates and visual cues without requiring linear, inefficient scaling of compute resources. ### The Constraint Optimization Problem To maintain a seamless experience, Netflix engineers balance three primary technical constraints: time to update, request throughput, and compute cardinality. * **Time:** The specific duration required to coordinate and push a recommendation update to the entire global fleet. * **Throughput:** The maximum capacity of cloud services to handle incoming requests without service degradation. * **Cardinality:** The variety and complexity of unique requests necessary to serve personalized updates to different user segments. ### Two-Phase Recommendation Delivery The system splits the delivery process into two distinct stages to smooth out traffic spikes and ensure high availability. * **Prefetching Phase:** While members browse the app normally before an event, the system downloads materialized recommendations, metadata, and artwork into the device's local cache. * **Broadcasting Phase:** When the event begins, a low-cardinality "at least once" message is broadcast to all connected devices, triggering them to display the already-cached content instantaneously. * **Traffic Smoothing:** This approach eliminates the need for massive, real-time data fetches at the moment of kickoff, distributing the heavy lifting of data transfer over a longer period. ### Live State Management and UI Synchronization A dedicated Live State Management (LSM) system tracks event schedules in real time to ensure the user interface stays perfectly in sync with the production. * **Dynamic Adjustments:** If a live event is delayed or ends early, the LSM adjusts the broadcast triggers to preserve accuracy and prevent "spoilers" or dead links. * **Visual Cues:** The UI utilizes "Live" badging and dynamic artwork transitions to signal urgency and guide users toward the stream. * **Frictionless Playback:** For members already on a title’s detail page, the system can trigger an automatic transition into the live player the moment the broadcast begins, reducing navigation latency. To support global-scale live events, technical teams should prioritize edge-heavy strategies that pre-position assets on client devices. By shifting from a reactive request-response model to a proactive prefetch-and-trigger model, platforms can maintain high performance and reliability even during the most significant traffic peaks.

Real Time Data Distributed Systems Recommendation Systems Caching+4

datadogAug 12, 20253 min readCurated summary

Scaling down to speed up: How we improved efficiency of live process metrics by 100x

Datadog redesigned its real-time Processes and Containers pipeline to avoid collecting high-frequency metrics that users never see. By limiting 2-second collection to hosts actively viewed and using standard 10-second data for sorting, the company reduced real-time traffic by over 100x, cut infrastructure costs by 98%, and lowered Agent resource usage. The approach also improved scalability without sacrificing the live investigation experience. ## Original Real-Time Collection Model - Datadog Agents normally collect process and container metrics every 10 seconds. - When a user opened a live Processes or Containers view, all hosts in that tenant switched to 2-second collection. - This supported near-real-time monitoring similar to `htop`, but across distributed infrastructure. - As tenants grew, the pipeline had to process millions of processes per second, even though users typically viewed only around 50 processes or containers. - Live sorting required keeping all tenant data in memory on a single server, limiting horizontal scaling and forcing vertical scaling. ## Refocusing on User-Visible Data - Most collected metrics were never displayed to users. - Datadog determined that real-time collection only needed to be enabled for hosts running the processes or containers currently in view—up to roughly 50 hosts per user. - Internal telemetry suggested this could reduce traffic by more than 100x. - This required tracking active host subscriptions and updating them as users navigated the product. - Because sorting occurred every 10 seconds, it did not need 2-second data. Datadog switched live views to use the existing 10-second metrics, aligning live and historical sorting logic. ## Host Subscription Filtering - A proof of concept added host subscriptions to the live data servers. - Servers filtered Kafka payloads and discarded data for hosts without active subscriptions. - This immediately reduced: - Memory usage by 85% - CPU usage by 33% - The improvement came from storing fewer live metrics and processing fewer incoming payloads. - The prototype confirmed that filtering preserved product behavior while simplifying sorting. ## Moving Filtering Earlier in the Pipeline - Late filtering improved live data servers but still left unnecessary work for the rest of the system and customer-side Datadog Agents. - Datadog therefore planned to propagate subscription state to the intake service. - Live data servers publish users’ active host sets over Kafka once per second. - The intake service consumes this information and decides which hosts should activate 2-second process and container metric collection. - This allows real-time collection to be restricted to hosts users are actively investigating while maintaining responsive live views. Datadog’s redesign demonstrates that real-time systems scale more effectively when they prioritize data users can actually see. Filtering at intake, limiting high-frequency collection to subscribed hosts, and reusing standard-resolution data for sorting provide a simpler and more economical architecture without eliminating live functionality.

Read original

Real Time Data Database Design Datadog Apache Kafka+4

figmaMay 16, 20242 min readCurated summary

Keeping It 100(x) With Real-time Data At Scale | Figma Blog

Figma’s LiveGraph powers real-time collaboration by subscribing to GraphQL-like queries and updating clients automatically. Rapid growth—tripled sessions since 2021 and fivefold view-request growth in one year—exposed limits in its single-server, mutation-based architecture. Figma launched “LiveGraph 100x,” a redesign focused on scaling reads and database updates while preserving performance and enabling a safe migration. ## LiveGraph’s Role in Figma - LiveGraph keeps data synchronized across collaborative features such as: - File editing - Comments - FigJam voting - It exposes a web API for subscribing to GraphQL-like queries. - Results are returned as JSON trees based on a schema of entities, relationships, and views. - A custom React Hook automatically re-renders interfaces when subscribed data changes. ## The 100x Scaling Initiative Figma’s growing user base increased both the number and cost of LiveGraph client sessions. At the same time, the underlying database evolved from one PostgreSQL instance into vertically and horizontally sharded infrastructure. The redesigned system needed to: - Preserve or improve service-level objectives for initial loads and updates. - Support more database shards reliably and efficiently. - Scale reads and database-update processing independently. - Allow incremental, transparent migrations without disrupting users. ## Limitations of the Original Architecture Originally, LiveGraph consisted of: - A single LiveGraph server. - An in-memory query cache. - One PostgreSQL instance. - A cache that tailed PostgreSQL’s logical replication stream. PostgreSQL writes row mutations to its write-ahead log, including pre- and post-row images and a monotonically increasing sequence number. LiveGraph used these mutations to update cached query results directly rather than recomputing them. This design worked well at smaller scale because: - All updates came from one primary database. - The replication stream provided a global ordering. - Each row mutation could be applied directly to the relevant cached results. ## Sharding Breaks Global Ordering As the original PostgreSQL instance reached capacity, Figma introduced vertical shards and began moving toward broader horizontal scaling. This invalidated the assumption that all database updates arrive in one globally ordered stream. - Multiple shards can generate updates simultaneously. - Their updates have no guaranteed global order. - LiveGraph therefore needed an architecture that could process distributed database changes while maintaining reliable, timely query updates. The growing load made it necessary to rethink LiveGraph fundamentally rather than continue extending its single-database design.

Read original

Real Time Data PostgreSQL Distributed Systems GraphQL+4

figmaOct 13, 20213 min readCurated summary

LiveGraph: real-time data fetching at Figma | Figma Blog

LiveGraph is Figma’s in-house real-time data-fetching layer built on PostgreSQL. It lets frontend developers declare live data views with GraphQL-like queries, while LiveGraph reads PostgreSQL’s replication stream to deliver updates within milliseconds. Figma built it to replace fragile, manually maintained client events and to support real-time subscriptions at large scale without relying on polling or a new database technology. ## Problems with Figma’s Earlier Real-Time Architecture - React clients initially loaded large data sets through Ruby HTTP endpoints and stored them in Redux. - Backend code manually emitted events whenever database records changed. - Frontends subscribed over WebSockets and applied those events to client state. - As data volumes grew, Figma split requests into incremental loads, making data ownership and availability harder to reason about. - Complex changes—such as permission updates affecting many resources—were difficult to represent with individual events. - Events could arrive out of order or fail to correspond reliably with database writes, causing client state to diverge from server state. ## Why Figma Chose Live Queries - Figma wanted developers to define data subscriptions declaratively rather than manually coordinate fetches and update events. - GraphQL provided a natural interface for describing the relevant portion of the object graph. - LiveGraph uses “live queries,” which keep query results synchronized, rather than GraphQL subscriptions in the narrower sense of consuming event streams. - The system is a query and data-fetching layer over existing PostgreSQL infrastructure, not a replacement persistence layer. ## In-House System Versus Existing Tools - Figma’s multiplayer service handles collaborative writes and conflict resolution within individual files, whereas LiveGraph focuses on reading application data. - Systems such as Hasura, Prisma, and PostGraphile offered GraphQL subscription features but were not designed primarily for Figma’s scale of concurrent live subscriptions. - Polling was rejected because it increases database load and requires developers to choose polling intervals for each query. - Figma’s collaborative product made real-time data central enough to justify building and operating a specialized internal system. - The company did not claim LiveGraph was universally superior; its value came from matching Figma’s specific scale and requirements. ## Replication-Stream-Based Updates - LiveGraph executes queries directly against PostgreSQL. - It tails the database replication log to detect changes instead of repeatedly polling tables. - Reading the replication stream enables update latency measured in milliseconds. - Because the system must process the complete volume of database changes, its architecture needs to distribute updates across machines and database shards. - This approach separates the complexity of detecting database changes from product code, allowing frontend engineers to work with declarative JSON data views. ## Frontend API - Product developers send GraphQL-like queries and receive results as JSON trees. - A schema defines server-side entities and relationships, while views expose queryable subsets of that graph. - The frontend can therefore request the data it needs and rely on LiveGraph to keep the result synchronized as the underlying PostgreSQL data changes. LiveGraph’s central recommendation is architectural: derive live client views from the database’s authoritative change stream rather than maintaining a parallel network of hand-written events. For organizations with similar scale and real-time requirements, this can improve consistency and simplify product development, though Figma’s in-house approach was justified by its unusually collaborative workload.

Read original

Real Time Data React PostgreSQL TypeScript+4