line·Apr 10, 2026·4 min readCurated summary

Clearing Review Bottlenecks with AI - Transforming Review Culture with PR Review Support and Internal Workshops

Orchestration Guild member Fukuyama describes how Yahoo! Places addressed PR review bottlenecks by combining AI assistance with standardized processes and team culture. Reviews had become concentrated among a few engineers, creating delays and forcing a trade-off between speed and quality. The team introduced Claude Code–based screening reviews, then expanded the approach into a broader system for improving PR creation, review accuracy, and continuous improvement. ## PR Review Bottlenecks - In late 2024, review responsibilities were concentrated on the tech lead and one other engineer. - Reviewers were simultaneously implementing features and reviewing code, causing PR queues to grow. - The main problems were: - Authors could not move to their next tasks while waiting for reviews. - Review work consumed most of the day. - Large PRs had to be reviewed quickly, increasing the risk of missed bugs. - This created a single point of failure and exposed the trade-off between thoroughness and development speed. - The launch of a dedicated frontend team in early 2025 provided an opportunity to redesign the review process. ## Introducing AI Screening Reviews - The team first tried having AI summarize PR changes before review. - Although summaries made changes easier to understand, AI did not sufficiently reduce the work of tracing dependencies or identifying hidden problems. - Manually pasting prompts for every review also made the approach inconvenient, so it was abandoned after about two weeks. - The introduction of Claude Code in summer 2025 changed the situation because reusable custom commands eliminated repetitive prompt preparation. - AI screening reviews now perform an initial inspection before a human reviewer makes the final judgment. - This changes the process from “humans inspect everything” to a two-stage model: - AI analyzes the PR, its impact, coding conventions, and possible risks. - A human reviewer validates the analysis and makes the final decision. ## Claude Code Custom Review Commands The custom command requests that Claude Code: - Summarize the PR and its affected areas. - Explain the before-and-after changes for each file. - Check coding and naming conventions. - Investigate dependent files and broader codebase impact. - Identify potential bugs, security issues, performance problems, code smells, and unintended side effects. - Suggest concise, respectful review comments for the author. - Classify comments with labels such as `[must]`, `[want]`, `[imo]`, `[ask]`, `[nits]`, and `[info]`. - Determine whether additional tests are needed based on existing project practices. The command uses GitHub CLI operations such as: - `gh pr view --json title,body,files,url` - `gh pr diff` - `gh pr view --comments` - GitHub API calls for line-level comments - `gh pr checkout` when the relevant branch is not currently checked out The review procedure is deliberately structured: 1. Confirm the review requirements. 2. Understand the PR’s overall purpose and background. 3. Review each changed file in detail. 4. Investigate dependencies across the codebase. 5. Produce a final assessment and suggested comments. The same screening process can help both reviewers and PR authors. Reviewers use it to reduce preparation time and understand impact, while authors can run it before requesting review to fix likely issues in advance. ## Expanding Beyond AI Screening After seeing benefits from screening reviews, the team created a broader improvement framework spanning technology and team culture. It was organized around four connected goals: - Improving efficiency. - Establishing a foundation for review accuracy. - Building review-oriented team culture. - Creating a mechanism for continuous improvement. The approach treats review optimization as an ongoing cycle rather than a one-time tool deployment. ## Automating PR Creation The team also uses AI to reduce the effort required to create PRs. - Git operations such as branch creation, commits, and PR creation are automated. - AI analyzes the commit diff to generate: - A PR title. - A summary of the changes. - Background and motivation. - Other required PR template fields. - Standardized and more complete PR descriptions provide better context for both human reviewers and AI screening. - Improving PR quality at the creation stage also increases the accuracy and consistency of later reviews. ## Practical Recommendation AI should support—not replace—reviewer judgment. Teams should begin by standardizing the review workflow, encode that workflow in reusable AI commands, and measure whether review time, PR waiting time, and review quality improve. Combining AI screening with better PR context, dependency analysis, clear comment conventions, and continuous process refinement offers a more sustainable solution than relying on individual reviewers.

Read original(opens in new tab)

Database DesignAIWeb DevelopmentClaude Code+4

google·Apr 9, 2026·3 min readCurated summary

ConvApparel: Measuring and bridging the realism gap in user simulators

ConvApparel addresses the “realism gap” between LLM-based user simulators and genuine human behavior. It combines over 4,000 human-AI shopping conversations with a controlled Good-versus-Bad agent setup and evaluates simulators through statistical alignment, human-likeness, and counterfactual adaptation. The framework aims to determine whether simulators genuinely model human reactions or merely reproduce patterns from their training data. ## Why User Simulator Realism Matters - Conversational agents often fail during long, multi-turn interactions by forgetting constraints or producing irrelevant responses. - Human testing provides valuable feedback but is expensive, slow, and difficult to scale. - LLM-based user simulators offer a scalable alternative, but often behave unlike real users: - They may be excessively verbose. - They can lack consistent personas or coherent preferences. - They may possess unrealistic, encyclopedic knowledge. - They are often unusually patient and assistant-like. - Training systems only against unrealistic simulators may cause them to fail with real users. ## The Need for Counterfactual Validation - A simulator should respond plausibly not only to situations represented in its training data, but also to novel assistant behaviors. - The authors introduce **counterfactual validation**: training a simulator on helpful-agent conversations, then testing it against an unexpectedly frustrating agent. - A realistic simulator should recognize poor assistance and show increased frustration, reduced satisfaction, and behavior changes similar to those of real users. - This tests whether the simulator has learned general human behavior rather than memorized training patterns. ## The ConvApparel Dataset - ConvApparel contains more than 4,000 human-AI multi-turn conversations and nearly 15,000 total turns in the apparel-shopping domain. - Participants were unknowingly assigned to one of two recommendation agents: - **Good agent:** Helpful, efficient, and supported by robust search. - **Bad agent:** Intentionally confusing, tangential, and based on degraded search retrieval. - The dataset captures reactions ranging from satisfaction to significant annoyance. - Participants provided turn-by-turn retrospective annotations, including: - Satisfaction - Frustration - Likelihood of making a purchase ## Three-Part Evaluation Framework ### Population-Level Statistical Alignment - Simulated conversations are compared with human conversations using aggregate measures such as: - Conversation length - Words per turn - Dialogue acts, including rejecting recommendations - This reveals whether simulators reproduce broad behavioral distributions. ### Human-Likeness Score - An automated discriminator is trained on human and simulated conversations. - It produces a probability indicating how human-like a conversation appears. - The score is intended to detect subtle stylistic differences that simple statistics may miss. ### Counterfactual Validation - A simulator is trained only on conversations with the Good agent. - It then interacts with the unseen Bad agent. - High-fidelity simulation should produce a human-like increase in frustration and decline in satisfaction when the assistant behaves poorly. ## Simulator Configurations The experiments compare three Gemini-based user simulators: - **Prompted simulator:** Uses high-level behavioral instructions without additional task-specific training. - **In-context learning (ICL) simulator:** Retrieves semantically similar human conversations from ConvApparel and supplies them as examples at each turn. - **Supervised fine-tuning (SFT) simulator:** Trains a Gemini 2.5 Flash model directly on the dataset. The post presents ConvApparel as a structured way to measure simulator realism and test whether simulated users can adapt to assistant behavior outside their training distribution. Its central recommendation is to evaluate user simulators not only by surface-level similarity, but also by how naturally they react to unexpected failures.

Read original(opens in new tab)

Database DesignLarge Language ModelsGeminiConversational Ai+4

line·Apr 8, 2026·3 min readCurated summary

The Key to AI Utilization Lies in 'Organizational Learning' - The Start of the Orchestration Development Workshop

LY Corporation is moving from simply adopting AI tools to building with AI as a collaborative development partner. Its new Orchestration Development Workshop teaches engineers to coordinate multiple AI systems across coding, testing, reviews, incident analysis, and other workflows. The initiative aims not only to improve efficiency but to free engineers from repetitive work so they can focus on more creative, high-value challenges. ## From AI Adoption to AI Collaboration - AI-assisted development and operations are spreading rapidly across LY Corporation. - Engineers use generative AI for code generation and testing, while combining it with non-generative AI for analysis and operational optimization. - Despite broader adoption, employees differ significantly in how deeply they use AI in their daily work. - The workshop was created to help the organization evolve from “using AI” to “creating alongside AI.” ## Orchestration: Coordinating Multiple AI Systems - “Orchestration” refers to combining multiple AIs, along with human input, to produce a complete outcome. - Example workflows include: - Generating code automatically from a Jira ticket. - Having AI run tests, conduct reviews, and create a pull request. - Analyzing a Slack incident report, estimating the cause, and proposing a fix. - The workshop turns these emerging practices into hands-on learning rather than passive demonstrations. ## A Hands-On, Interactive Learning Model - Participants follow instructors in real time and perform the same tasks themselves. - Zoom conversations and Slack questions create two-way communication during the session. - Instructors and representative participants explore solutions to problems as they arise. - The goal is for attendees to gain skills they can reproduce in their own projects, not merely acquire theoretical knowledge. ## Organization-Wide Support Through Guilds and DevRel - The initiative is designed to avoid depending on individual enthusiasm. - Three complementary functions support continuous growth: - **DevRel:** Drives the program and promotes adoption. - **Guilds:** Contribute practical insights from engineering teams. - **TD:** Helps maintain quality and reproducibility. - This structure supports consistent content quality and enables AI knowledge to spread across the company. ## Beyond Efficiency: Unlocking Engineering Creativity - LY Corporation views AI as more than a way to complete tasks faster. - By delegating repetitive work to AI, engineers can spend more time on creative and strategically valuable activities. - The organization aims to move beyond a model where AI writes code and humans only review it. - Instead, engineers should collaborate with AI from the design stage through implementation. ## Future Direction - LY Corporation plans to share lessons from the workshops through external channels such as its technology blog. - Future topics will include both generative and non-generative AI. - The broader goal is to provide practical guidance for engineers building new workflows with AI. The workshop represents a structured way to turn AI experimentation into repeatable organizational practice, helping engineers coordinate multiple AI tools while preserving human creativity and judgment.

Read original(opens in new tab)

Database DesignAIPostgreSQLPython+4

stripe·Apr 7, 2026·3 min readCurated summary

How agents, digital wallets, and trust are rewriting checkout

The internet economy is reshaping checkout around mobile purchasing, digital wallets, local payment preferences, and AI-assisted shopping. Stripe’s analysis of nearly 20,000 B2C businesses shows that customers increasingly complete expensive purchases on mobile, expect region-specific payment options, and are becoming more open to buying through AI agents. Businesses that adapt checkout to local behavior and manage fraud intelligently can improve conversion while reducing unnecessary declines. ## Mobile Checkout Is Expanding to Higher-Value Purchases - Mobile dominates purchases under $50, but shoppers are increasingly using phones for purchases over $500. - This trend is strongest in APAC and EMEA, where mobile is already the preferred checkout device. - In the US, mobile gained share across every purchase range measured over the past two years. - Canada is an exception, with shoppers more likely to switch to desktop for purchases between $100 and $249. ## Digital Wallets Depend on Region and Generation - Digital wallets represent roughly 30% of global point-of-sale volume. - Sixty-one percent of surveyed shoppers said they would use a digital wallet. - Younger shoppers are especially likely to use wallets, including for purchases over $250. - Wallets cut average mobile checkout time in half, making speed a major advantage. - Preferences vary by market, from MB WAY in Portugal and MobilePay in Denmark to Alipay in China. - Businesses need to support the wallet mix that is actually popular in each region rather than relying only on Apple Pay, Google Pay, and similar global options. ## Localization Requires the Right Payment Mix - Forty-five percent of surveyed consumers made at least one international online purchase in the previous year. - International demand does not guarantee conversion; checkout must match local expectations for currency, payment methods, and presentation. - Markets such as Indonesia and Vietnam have fragmented preferences across wallets, bank transfers, debit-linked apps, and other local methods. - In more concentrated markets, conversion may depend heavily on supporting one dominant payment method. - Showing an irrelevant payment option can reduce conversion by up to 15%. - Supporting local leaders can significantly improve results: - BLIK increased Polish checkout conversion by an average of 46%. - Pix increased Brazilian checkout conversion by an average of 31%. ## AI Agents Are Changing Checkout and Payment Risk - Consumers are increasingly open to AI agents helping with purchase decisions. - Shopping and product discovery are moving into tools such as Google Gemini, Microsoft Copilot, visual search systems, and retailer-specific assistants. - Automated fraud, including card testing, is becoming easier to scale. - Overly strict risk controls can reject legitimate customers along with fraudulent transactions. - New payment models use more real-time signals, selective authentication, and improved routing and retries to balance fraud prevention with conversion. - Stripe reports that its AI-driven interventions can reduce fraud by 30% without lowering conversion. ## Checkout Becomes a Verification Layer Checkout is evolving beyond a final payment screen into a system that verifies identity, purchase intent, and authorization. Businesses should prioritize mobile performance, offer payment methods that reflect each market’s behavior, and prepare for transactions initiated by AI agents. The strongest checkout experiences will be fast, locally relevant, and capable of distinguishing legitimate buyers from automated fraud.

Read original(opens in new tab)

Database DesignStripeAi AssistantPayment Methods+4

gitlab·Apr 7, 2026·3 min readCurated summary

Pipeline security lessons from March supply chain incidents

Between March 19 and 31, 2026, attacks on Trivy, KICS, LiteLLM, and axios demonstrated that CI/CD pipelines are valuable supply-chain targets. The incidents exploited trusted tools, stolen credentials, packaging mistakes, and malicious dependencies to steal secrets or leak proprietary code. The article argues that centralized, mandatory pipeline policies can detect and block these patterns before they reach production. ## Recent Supply-Chain Incidents - **Trivy:** Attackers compromised GitHub Action tags and distributed a trojanized binary that harvested environment variables, cloud tokens, SSH keys, and CI/CD secrets. - **Checkmarx KICS:** Malicious versions of KICS GitHub Actions exfiltrated API keys, database passwords, cloud credentials, and service-account secrets. - **LiteLLM:** Backdoored PyPI releases executed payloads during installation or Python startup, stealing sensitive files and credentials. - **AI coding assistant package:** A 59.8 MB source map unintentionally exposed more than 1,900 TypeScript files, internal feature flags, model codenames, and a system prompt. - **axios:** Compromised maintainer credentials enabled malicious releases containing a cross-platform Remote Access Trojan through a poisoned dependency. ## Three Attack Patterns ### Poisoned Tools and Actions - Pipelines often implicitly trust security scanners, GitHub Actions, package versions, and container images. - Mutable tags can be changed after approval, causing future pipeline runs to execute malicious code. - Recommended controls: - Pin actions and tools to commit SHAs or image digests. - Verify checksums or signatures. - Block execution when integrity checks fail. ### Packaging Errors That Expose Intellectual Property - Incorrect `.npmignore` files or `files` settings can include source maps, internal configuration, and other debugging artifacts in published packages. - Pre-publish validation should compare package contents against an allowlist. - Builds should flag unexpected source maps, `.env` files, and internal files, then block publication when violations occur. ### Malicious Transitive Dependencies - A compromised dependency can affect users who never directly selected it. - Unexpected lockfile changes or newly introduced packages can spread attacks across an organization. - Recommended controls: - Compare dependency checksums with known-good lockfile state. - Detect unexpected dependency or version changes. - Reject unverified packages during builds. ## GitLab Pipeline Execution Policies - GitLab Pipeline Execution Policies inject mandatory CI/CD jobs into pipelines across an organization. - Policy-defined jobs cannot be bypassed through `[skip ci]` or `[no_pipeline]`. - Jobs can run in reserved pre- and post-pipeline stages, surrounding developer-defined jobs. - GitLab’s open-source Supply Chain Policies project provides independently deployable policies and sample violations for testing the three attack patterns. The practical recommendation is to make supply-chain validation mandatory and centralized: pin trusted inputs, inspect published artifacts, verify dependency changes, and block builds or releases when policy checks fail.

Read original(opens in new tab)

Database DesignCI/CDOpen SourceTrivy+4

netflix·Apr 6, 2026·4 min readCurated summary

Stop Answering the Same Question Twice: Interval-Aware Caching for Druid at Netflix Scale

Netflix’s Druid deployment now exceeds 10 trillion rows and can ingest 15 million events per second, but repetitive dashboard queries became a scaling problem. Its new experimental caching layer handles rolling time windows by reusing settled historical results and querying Druid only for recent, changing data. Netflix accepts up to five seconds of additional staleness in exchange for substantially lower query load. ## The Scaling Problem - A dashboard with 26 charts can issue 64 queries per load. - Viewed by 30 people and refreshed every 10 seconds, that becomes roughly 192 queries per second. - Druid’s full-result cache misses whenever a rolling time interval changes. - Druid avoids caching realtime segments to preserve result correctness and determinism. - Per-segment caching reduces historical scans but still requires brokers to gather and merge results for every request. - Adding hardware to handle this redundant workload would be prohibitively expensive. ## Caching Only the Unsettled Data - In a three-hour query, most data is already stable; only the newest minutes are likely to change. - The cache stores previously returned historical portions and sends Druid only the uncached interval. - This approach is designed for time-grouped queries such as timeseries and groupBy queries. ## Deliberate Staleness - The cache can make the newest data up to five seconds stale. - This is acceptable because dashboards typically refresh every 10–30 seconds. - Netflix’s pipeline already has up to roughly five seconds of latency at P90. - Many queries also intentionally end at `now-1m` or `now-5s` to avoid unstable, newly arriving data. ## Exponential TTLs - Cache lifetimes increase with the age of each data point because older data is less likely to change. - Data under two minutes old has a minimum TTL of five seconds. - After that, TTL doubles for each additional minute: - 10 seconds at two minutes old - 20 seconds at three minutes - 40 seconds at four minutes - TTLs are capped at one hour. - Fresh data is refreshed frequently to account for late-arriving events, while older data remains cached longer. ## Time-Based Bucketing - A single cache entry per query and interval would still miss whenever a rolling window shifted. - Netflix instead uses a map-of-maps: - The outer key is a hash of the query excluding its time interval. - Inner keys represent timestamps bucketed by query granularity or at least one minute. - Big-endian timestamp encoding preserves chronological order for efficient range scans. - A three-hour query at one-minute granularity becomes 180 independently cached buckets. - When the window moves, most buckets can be reused and only the newly exposed range must be fetched. ## Router-Integrated Cache Service - The cache currently operates as an external service behind the Druid Router. - Cacheable requests are intercepted transparently: - Fully cached requests are answered directly. - Partially cached requests are narrowed to the missing interval and sent to Druid. - Metadata queries and queries without time-based grouping bypass the cache. - The proxy can be enabled or disabled without changing clients. - Netflix views this as an interim design while exploring deeper integration with Druid. ## Query Identification and Lookup - Incoming queries are parsed to extract their interval, granularity, and structure. - A SHA-256 hash is generated from the query’s logical contents, including datasource, filters, aggregations, and relevant context properties, while excluding the time interval. - The cache looks for buckets within the requested range. - Lookup requires cached buckets to be contiguous from the beginning of the requested interval; the provided article text ends while explaining the handling of expired or missing buckets. Netflix’s approach is best suited to frequently repeated rolling-window dashboards where a small, slightly stale tail is acceptable. Segmenting results by time and assigning age-based TTLs allows the system to preserve freshness where it matters while eliminating most redundant Druid work.

Read original(opens in new tab)

Database DesignCachingQuery OptimizationData Ingestion+3

cloudflare·Apr 6, 2026·3 min readCurated summary

How we built Organizations to help enterprises manage Cloudflare at scale

Cloudflare’s new Organizations feature helps enterprises centrally manage users, policies, accounts, and analytics across multiple Cloudflare Accounts. It preserves least-privilege access by allowing teams to remain separated while giving designated organization administrators broader oversight. Initially available in public beta for enterprise customers, Organizations is designed to reduce administrative complexity without granting unauthorized access. ## Why Enterprises Use Multiple Accounts - Separate accounts help teams manage their own resources and limit permissions. - Fine-grained RBAC can still be cumbersome when administrators must enumerate individual resources. - Central administrators currently need access to every account for reporting and policy management. - This setup is fragile because account-level administrators can remove those central administrators. ## Organization Structure and Account Management - Organizations add a management layer above individual Cloudflare Accounts. - The core feature is a flat list of accounts onboarded into the organization. - An account can be added only by someone who is a Super Administrator for that account. - Organizations are built on Cloudflare’s existing Tenant system, originally developed for partners. ## Organization Super Administrators - Org Super Administrators have Super Administrator permissions across every account in the organization. - They do not need memberships in child accounts and do not appear in account-level user interfaces. - The new role is the first of several planned organization-level roles. - Cloudflare consolidated legacy authorization paths into domain-scoped roles. - The permissions overhaul added approximately 133,000 lines of code and removed 32,000. - Permission checks for enumeration endpoints such as `/accounts` and `/zones` became 27% faster, especially for users with access to thousands of accounts. ## Organization-Wide Analytics - Org Super Administrators can view aggregated HTTP traffic analytics. - The dashboard combines data across all accounts and zones in the organization. - Cloudflare plans to add analytics for additional products over time. ## Shared Configurations - Organizations allow centrally managed policy sets to be shared across accounts. - Initial examples include WAF and Gateway policies. - Authorized users in the source account can update shared policies for the broader enterprise. - Security analysts can therefore manage enterprise-wide WAF rules without becoming organization or account administrators everywhere. ## Roadmap and Availability - The beta initially targets enterprise customers. - Cloudflare plans to expand access to pay-as-you-go and other customers, followed by the partner ecosystem. - Planned capabilities include: - Organization-level audit logs - Billing reports - More analytics dashboards - Additional organization user roles - Self-service account creation ## Security-First Rollout - Cloudflare will not automatically create organizations through account backfilling. - A self-service invitation process ensures that no user gains access without approval from a relevant Super Administrator. - The first eligible Super Administrator to claim the company’s organization can add other accounts where they also hold Super Administrator access. - If another employee has already claimed the organization, administrators must coordinate invitations or account-level approval. - Cloudflare Support will not configure organizations on customers’ behalf. Enterprise customers can claim an organization from the Cloudflare Dashboard’s Organizations tab at no additional cost. Companies should coordinate internally with their Super Administrators to ensure all relevant accounts are added securely.

Read original(opens in new tab)

Database DesignCloudflareWeb Application FirewallAnalytics+4

meta·Apr 6, 2026·4 min readCurated summary

How Meta Used AI to Map Tribal Knowledge in Large-Scale Data Pipelines

AI coding assistants struggle when they lack a map of a large, proprietary codebase. To address this, the team built a pre-compute system using 50+ specialized agents that analyzed over 4,100 files across four repositories and three languages, producing 59 concise context files. The approach gave agents complete module coverage, captured previously undocumented tribal knowledge, reduced tool calls by about 40%, and made complex development tasks much faster. ## The Problem: Powerful Tools Without Codebase Context - The pipeline combines Python configuration, C++ services, and Hack automation across multiple repositories. - A seemingly simple change, such as adding a data field, can affect: - Configuration registries - Routing logic - DAG composition - Validation rules - C++ code generation - Automation scripts - AI agents often explored repeatedly, guessed at conventions, and produced code that compiled but was subtly incorrect. - Important examples of missing context included: - Different field names for the same operation in separate configuration modes - “Deprecated” enum values that must remain for serialization compatibility - Hidden intermediate field names used between pipeline stages ## The Pre-Compute Approach The team used a large-context model and orchestrated specialized agents in several phases: - Two agents explored and mapped the codebase. - Eleven analysts read every file and answered five questions: - What does the module configure? - How is it commonly modified? - What non-obvious patterns can cause failures? - What are its cross-module dependencies? - What tribal knowledge is hidden in comments? - Writers generated context files. - More than ten critic passes reviewed quality across three rounds. - Fixers, upgraders, gap-fillers, prompt testers, and final critics corrected and validated the results. - In total, more than 50 specialized tasks were coordinated in one session. This process uncovered over 50 non-obvious design patterns, including naming conventions and append-only identifier rules that were not documented elsewhere. ## Context Files: “A Compass, Not an Encyclopedia” Each of the 59 context files is intentionally short—about 25–35 lines or roughly 1,000 tokens—and contains: - Quick Commands for common operations - Key Files limited to the most relevant three to five files - Non-Obvious Patterns - See Also references to related modules Together, the files use less than 0.1% of a modern model’s context window. They are designed for targeted, opt-in use rather than being loaded into every task. ## Routing and Dependency Navigation - An orchestration layer routes natural-language requests to the appropriate tool. - Operational questions can trigger dashboard scans and matching against more than 85 historical incident patterns. - Development requests can launch configuration generation and multi-phase validation. - A cross-repository dependency index and data-flow maps show how changes propagate. - Dependency questions that previously required about 6,000 tokens of exploration can be answered through a graph lookup using roughly 200 tokens. ## Results and Quality Controls - Preliminary tests across six tasks showed approximately 40% fewer tool calls and tokens. - Work that previously required around two days of research and engineer consultation took about 30 minutes. - Critic reviews raised quality scores from 3.65 to 4.20 out of 5. - Every referenced file path was verified, with no hallucinated paths. - Coverage expanded from navigation guidance for roughly 5% of modules to all 4,100+ files across three repositories. ## Why This Differs from Generic Context Files Research has found that AI-generated context files can reduce agent performance on familiar open-source projects. The team argues that this result does not directly apply to proprietary systems whose conventions and tribal knowledge are absent from model training data. Their approach addresses common problems by making context: - Concise rather than encyclopedic - Opt-in rather than always loaded - Quality-gated through independent critics - Continuously refreshed to prevent stale information Without this context, agents typically spend 15–25 tool calls exploring and remain vulnerable to subtle domain-specific errors. ## Keeping the Knowledge Fresh Automated jobs refresh the system every few weeks by: - Validating file paths - Detecting coverage gaps - Re-running critic reviews - Finding and repairing stale references - Updating routing and dependency information The system treats AI not merely as a consumer of documentation, but as the engine that creates and maintains it. ## Applying the Method Elsewhere Teams can adapt the approach by: - Identifying where agents most often fail due to undocumented conventions or dependencies - Applying the five-question analysis framework to each module - Keeping context files short and action-oriented - Using independent quality critics before publishing generated guidance - Automating freshness checks and self-repair The practical recommendation is to build a small, targeted, continuously maintained knowledge layer for proprietary codebases. Concise navigation and dependency context can reduce exploration costs while preventing the subtle errors that arise when agents lack domain-specific understanding.

Read original(opens in new tab)

Database DesignPythonCppConfig As Code+4

spotify·Apr 6, 2026·3 min readCurated summary

Background Coding Agents: Supercharging Downstream Consumer Dataset Migrations (Honk, Part 4) | Spotify Engineering

Spotify used its Honk background coding agent with Backstage and Fleet Management to automate migrations from two deprecated datasets to new versions. The effort targeted roughly 1,800 downstream pipelines and produced 240 automated pull requests, potentially saving about 10 engineering weeks. The experience showed that agents perform best when repositories follow standardized patterns, prompts contain precise technical context, and automated testing is available. ## The Challenge of Large-Scale Dataset Migrations - Two heavily used datasets needed replacement to support new dimensions and features. - The datasets had approximately 1,800 direct downstream pipelines and affected thousands more indirectly. - Migrations spanned three frameworks: - BigQuery Runner - dbt - Scala-based Scio - Manual migration was estimated to require around 10 engineering weeks within a six-month deadline. ## Using Backstage to Identify Consumers - Backstage’s endpoint lineage pages revealed downstream dataset consumers. - Its Codesearch plugin located relevant repositories across Spotify’s GitHub Enterprise environment. - The Fleetshift plugin used those results to organize and orchestrate repository migrations. - Backstage also provided a centralized view for tracking progress and opening generated pull requests. ## Context Engineering for Honk - Honk needed detailed, self-contained prompts because it could not access external documentation, dataset schemas, MCPs, or custom Claude skills during execution. - Scio was excluded because its flexible, inconsistent implementations made it difficult to describe all migration cases in one reliable prompt. - BigQuery Runner and dbt were more standardized, making them better candidates for automation. - An initial prompt based on a human migration guide was insufficient and caused incorrect assumptions about field mappings. - Explicit mapping tables in the context file significantly improved results. - Prompts also specified cases where fields should not be migrated automatically. - Honk left those fields unchanged. - It added comments linking to human migration guidance for later review. ## Testing and Automated Pull Requests - BigQuery Runner and dbt repositories generally lacked build-time unit tests. - As a result, Honk could not automatically verify and correct its changes, one of its key capabilities. - Downstream teams had to manually test the generated pull requests before merging. - Despite this limitation, the team successfully created 240 automated migration PRs. - Fleetshift’s Backstage interface simplified monitoring, troubleshooting, repository navigation, and communication with owning teams. ## Lessons for Future Agent-Driven Maintenance - Large-scale automation depends on standardizing frameworks and data practices across repositories. - Consistent testing and validation requirements are essential so agents can verify their own changes. - Future Honk functionality will allow agents to gather context from sources such as JIRA tickets and documentation before editing code. - Better context gathering should reduce the need for exhaustive prompt files and improve migration quality. Spotify’s experience suggests that background coding agents can substantially reduce migration toil, but their effectiveness depends on disciplined standardization, explicit migration rules, and strong automated testing.

Read original(opens in new tab)

Database DesignData PipelineBigqueryDbt+4

netflix·Apr 4, 2026·3 min readCurated summary

Powering Multimodal Intelligence for Video Search

Video search is difficult because it must combine many kinds of information—characters, scenes, dialogue, labels, and embeddings—across enormous volumes of footage. The post argues that solving this problem requires a distributed pipeline that separates reliable ingestion, computationally intensive data fusion, and low-latency search indexing. Temporal bucketing, hybrid ranking, and deduplication turn billions of model outputs into searchable moments for editors. ## Why Video Search Is Complex - Video contains multiple overlapping modalities, each analyzed by specialized models. - Models produce different outputs, including: - Text labels such as characters or objects - Scene classifications - High-dimensional embedding vectors - Time ranges with varying boundaries - Overlapping model timelines must be synchronized into a chronological representation. - A 2,000-hour archive may contain more than 216 million frames, expanding to billions of records after multimodal processing. - Search must avoid returning thousands of redundant clips from continuous shots. - Ranking therefore combines: - Symbolic text matching for precision and interpretability - Semantic vector similarity for contextual relevance - Clustering and deduplication to identify the best moments - Sub-second response times are essential because delays interrupt editors’ creative workflows. ## Three-Stage Ingestion and Fusion Pipeline ### Transactional Persistence - Raw model annotations are ingested through highly available pipelines. - Apache Cassandra stores the annotations with an emphasis on: - Data integrity - Distributed availability - High write throughput - An annotation can include a type, nanosecond time range, embedding vector, label, and confidence score. ### Offline Data Fusion - After persistence, Apache Kafka publishes an event that starts asynchronous processing. - The offline pipeline performs expensive temporal intersections without slowing ingestion or search. - Model outputs are normalized into fixed one-second time buckets. - The fusion process: - Maps continuous detections into discrete intervals - Intersects annotations sharing a bucket - Combines them into unified records - Writes the enriched records back to Cassandra - For example, a “Joey” character detection from seconds 2–8 can be combined with a “kitchen” scene detection from seconds 4–9 to create a fused record for the 4–5 second interval. - Each fused record retains links to the original annotations and source asset. ### Real-Time Search Indexing - Enriched buckets are later sent from Cassandra to Elasticsearch. - Upserts use a composite key consisting of the asset ID and time bucket. - If a bucket already exists, it is updated rather than duplicated. - This creates one consistent record for each second of footage while allowing new model results to be incorporated. The overall recommendation is to treat multimodal video search as a distributed data-fusion problem rather than a single-model retrieval task. Decoupling ingestion, offline processing, and indexing allows the system to handle massive archives while preserving reliable data capture and fast, context-rich search.

Read original(opens in new tab)

Database DesignApache KafkaElasticsearchApache Cassandra+4

line·Apr 3, 2026·4 min readCurated summary

From Hive to Iceberg: The Secret to 12x Faster Data Reflection

LINE Plus replaced a full-dump ETL pipeline for product data with incremental processing using Apache Iceberg and Apache Flink. The previous HBase/Hive workflow rewrote hundreds of millions of rows for every update, causing high compute costs and delays that left data up to an hour out of date. With the new architecture, update intervals were reduced from 60 minutes to 5 minutes—roughly a 12× improvement—while preserving consistency and fault tolerance. ## Limitations of Full-Data ETL - The existing HBase and Hive pipeline continuously collected CDC data in HDFS but had to merge it with existing data and rewrite the entire table before changes became queryable. - This caused: - High compute and storage costs - Dependence on limited shared Hadoop resources - Delayed updates and stale data - Snapshot-based extraction provides consistency, but large snapshots can take hours and retain old versions through MVCC, increasing system overhead. - Processing only the changed rows would reduce the workload from hundreds of millions of records to tens of thousands, separating update cost from total dataset size. ## Introducing Apache Iceberg - Iceberg manages data through metadata and table snapshots rather than relying solely on directory structures like traditional Hive tables. - It supports row-level `upsert` and `delete` operations. - This allows incremental changes to be written without rewriting the entire table, making much shorter ETL intervals possible. ## Requirements for the Streaming Pipeline The team evaluated Spark and Flink against three essential requirements: - **Data freshness:** Late-arriving compensation or replay data must not overwrite newer records. - **End-to-end exactly-once processing:** Iceberg updates and Kafka status messages must not partially succeed. - **Fault tolerance and state management:** Processing state must survive failures and restarts. A Kafka message indicating that all CDC data through a specific timestamp—such as 13:03—has been applied serves as the signal that a bulk extraction can safely begin. This requires complete confidence that the message accurately represents the Iceberg table’s committed state. ## Why Two-Phase Commit Was Necessary - Iceberg and Kafka are independent systems, so writing to one while failing to write to the other could create inconsistent state. - Two-phase commit (2PC) prevents partial success: - Both systems prepare their writes. - They commit only when all required operations succeed. - Any failure causes the operation to roll back. - Exactly-once processing also prevents duplicate or missing records during retries, network failures, or node restarts. - Together, these guarantees make Kafka status messages a reliable representation of the Iceberg table’s state. ## Choosing Flink over Spark - Spark Structured Streaming uses a micro-batch model, which makes fine-grained event-time and state control more difficult. - Flink provides native event-by-event streaming and better support for the required consistency model. - The team used Flink state to track each record’s `updatedate`: - Older late-arriving events are ignored. - Replayed historical data cannot overwrite newer values. - Flink checkpoints: - Persist streaming state externally. - Enable recovery from the latest consistent point. - Integrate with the Kafka sink’s 2PC mechanism. - Kafka messages remain in a pre-commit state until the Iceberg write and checkpoint both succeed. ## Kubernetes Deployment Options - The team compared: - **Native Kubernetes:** Requires manually configuring roles, service accounts, services, routing, deployments, slots, and jobs. - **Flink Kubernetes Operator:** Represents Flink infrastructure and jobs as custom resources, automating configuration such as routing and the web UI through Helm values. - Although Flink has greater operational complexity and a steeper learning curve than Spark, it was selected because it was the only option that satisfied all three core requirements at the engine level. The recommended architecture is an incremental Iceberg pipeline powered by Flink, with stateful processing, checkpoints, and two-phase commit between Iceberg and Kafka. This approach keeps data current, avoids expensive full-table rewrites, and provides reliable recovery and consistency at a five-minute update interval.

Read original(opens in new tab)

Database DesignKubernetesApache SparkApache Iceberg+4

dropbox·Apr 2, 2026·3 min readCurated summary

Improving storage efficiency in Magic Pocket, our immutable blob store

Magic Pocket’s immutable design protects data integrity but makes storage efficiency dependent on continuous reclamation. A new Live Coder service reduced write amplification while unintentionally creating severely under-filled volumes, driving fragmentation and storage overhead sharply upward. Dropbox responded by rethinking compaction, since its existing steady-state strategy was too slow to recover space from the resulting long tail of sparse volumes. ## The Cost of Immutability - Magic Pocket stores user files as immutable blobs distributed across its storage fleet. - Updates and deletions never modify data in place; obsolete blobs remain until compaction. - Garbage collection identifies unreferenced blobs, while compaction physically moves live blobs into new volumes and retires old ones. - Because closed volumes cannot be reopened, deleted data creates unused space unless it is actively consolidated. - Durability also increases storage requirements: - Replication stores multiple complete copies. - Erasure coding splits data into fragments and adds parity, providing fault tolerance with less overhead. - Fragmentation determines how efficiently that redundant capacity is used: - A volume with 50% live data effectively doubles required storage. - A volume with 10% live data uses roughly ten times the necessary space. ## The Live Coder Incident - A new on-the-fly erasure-coding service created severely under-filled volumes as it rolled out to new regions. - In the worst cases, less than 5% of a volume’s capacity contained live data. - Since volumes have fixed allocations, many mostly empty volumes consumed nearly as much raw capacity as full volumes. - Dropbox detected rising effective replication-factor signals, indicating more raw storage was being used per live byte. - The existing compaction system continued reclaiming space but was not designed for a long tail of extremely sparse volumes. - The incident demonstrated that compaction must adapt when the distribution of live data changes substantially. ## Steady-State L1 Compaction - Dropbox’s baseline strategy, L1, treats compaction as a packing problem. - It selects: - A highly filled host volume with available space. - Donor volumes whose live data fits into that space. - Live blobs from the donors are written into a new volume, eventually leaving the donors empty and removable. - L1 is simple, fast, and limits placement risk and metadata changes. - However, each run can read tens of GiB while typically producing only one densely packed volume. - Fewer than one complete volume is reclaimed on average because only donor volumes are fully drained. - This works well when volumes are already near full, but performs poorly when storage overhead is concentrated in many severely under-filled volumes.

Read original(opens in new tab)

Database DesignGarbage CollectionErasure CodingMagic Pocket+4

stripe·Apr 2, 2026·3 min readCurated summary

Insights from Shoptalk 2026: How agents are changing retail

Agentic commerce is already reshaping retail, especially product discovery, embedded checkout, and customer engagement across AI-powered surfaces. However, retailers still lack a common strategy for managing product data, choosing channels, and deciding between first-party and third-party agent experiences. The article argues that success will depend not only on agent-compatible infrastructure, but also on strong brands, unified customer data, and frictionless checkout. ## Agentic Commerce Needs a Standard Framework - Retailers are experimenting with where to begin, which partners to use, and how to syndicate accurate product data across AI platforms. - Search and discovery are changing quickly: - Sephora is using loyalty data in its ChatGPT app to personalize recommendations and highlight benefits such as samples and free shipping. - OpenAI reported that more than half of its searches are discovery-oriented, with 70% containing detailed constraints or context. - AI agents increasingly function as storefronts. Brands that are not discoverable through these systems risk losing visibility. - Direct product feeds are becoming important because they provide agents with more structured and current information than web crawling. - Stripe’s Agentic Commerce Suite allows retailers to connect catalogs and syndicate them across supported agents without building separate integrations. - Many companies are using test-and-learn programs to measure how products are discovered, recommended, and purchased through AI surfaces. ## Commerce Is Expanding Beyond Chat Interfaces - Agentic commerce is appearing across: - Embedded checkout - Product discovery - Customer service - Catalog enrichment - Post-purchase systems - Meta demonstrated a Facebook checkout flow using the Agentic Commerce Protocol, allowing shoppers to move from an ad to product information, AI-generated review summaries, and in-app purchase. - New consumer brands may increasingly be built on agentic infrastructure, reducing customer acquisition costs and dependence on standalone websites. - Retailers must decide how much to invest in first-party experiences versus third-party agents across categories such as fashion, beauty, and home goods. - The market is unlikely to be controlled by one large language model or channel; instead, commerce will spread across many specialized applications and surfaces. ## Brand Trust Becomes More Important - As AI simplifies comparison shopping, trust, consistency, and emotional connection will play a larger role in brand selection. - New Balance is emphasizing consistent quality, store improvements, and better-trained associates rather than relying primarily on discounts. - Tapestry is studying Gen Z to maintain Coach’s relevance, while Victoria’s Secret is focusing on comforting, confidence-building store experiences. - Stitch Fix is using first-party customer data to power Stitch Fix Vision, an AI tool for personalized outfit visualization. - Retailers will need unified customer data and systems that preserve identity and context across websites, stores, apps, and AI agents. ## Checkout and Commerce Infrastructure Remain Fundamental - Customers arriving through agent-driven journeys may be ready to buy and less tolerant of checkout friction. - Stripe says its Optimized Checkout Suite selects payment methods using more than 100 signals and typically increases conversion by 2%–3%. - Core requirements remain unchanged: - Fast, branded checkout - Relevant payment methods - Effective fraud prevention - Connected online, in-store, and in-app commerce data - Stripe’s Agentic Commerce Suite is designed to let businesses connect their catalog and commerce systems once, then expand into compatible agents and channels. Retailers should begin with structured product data, measurable experiments, unified customer systems, and a frictionless checkout experience. Agentic channels are developing rapidly, but durable brand value and strong commerce fundamentals will remain essential as those channels multiply.

Read original(opens in new tab)

Database DesignStripeChatgptAgentic Commerce+4

cloudflare·Apr 1, 2026·3 min readCurated summary

Introducing EmDash — the spiritual successor to WordPress that solves plugin security

EmDash is presented as a modern, TypeScript-based successor to WordPress, designed for today’s serverless hosting environment. Its central innovation is isolating plugins in sandboxed Dynamic Workers and granting them only explicitly declared capabilities. The project aims to preserve WordPress’s open-source publishing model while addressing plugin security, marketplace dependence, and licensing concerns. ## Modernizing WordPress for Today’s Web - WordPress powers more than 40% of the Internet but was designed when hosting commonly meant managing virtual private servers. - EmDash is: - Written entirely in TypeScript - Built on Astro - Serverless, while still deployable on personal hardware or Node.js servers - Fully open source and MIT licensed - Intended to remain compatible with WordPress-style functionality without using WordPress code - Version 0.1.0 is available as an early developer beta for Cloudflare or Node.js deployment, along with an online playground. ## Building on WordPress’s Publishing Legacy - WordPress democratized publishing and created a large ecosystem of core contributors, plugin developers, and theme developers. - The authors argue that WordPress will continue to have a role, but newer developers increasingly use Astro and TypeScript frameworks. - EmDash seeks to provide a similarly accessible, inexpensive, and open publishing platform suited to modern development practices. ## Sandboxed Plugins and Explicit Permissions - WordPress plugins are PHP scripts with direct access to the site’s database and filesystem. - This lack of isolation is identified as the source of most WordPress security problems: - 96% of WordPress site security issues reportedly originate in plugins. - High-severity vulnerabilities increased substantially in 2025. - EmDash runs each plugin inside an isolated Dynamic Worker. - Plugins access platform functionality through capability-based bindings rather than direct access to underlying resources. - A plugin must declare its required permissions in its manifest, allowing administrators to evaluate permissions before installation. - The example notification plugin: - Reacts to content-save events - Checks whether a post has been published - Sends an email to editors - Logs the notification - Plugins have no general external network access. If network access is necessary, the plugin can request permission for specific hostnames. - Administrators or platforms could enforce installation policies based on requested permissions instead of relying solely on approved-plugin allowlists. ## Security, Marketplaces, and Licensing - WordPress.org manually reviews plugins because the platform cannot otherwise guarantee their safety. - The review queue reportedly exceeds 800 plugins and can take at least two weeks. - Marketplace reputation, ratings, and reviews therefore become essential substitutes for technical trust. - Because WordPress plugins run inside WordPress and are tightly coupled to its code, developers may also face GPL licensing constraints. - The article argues that plugin security creates marketplace lock-in: - Customers rely on marketplaces to assess plugin trustworthiness. - Developers may need to distribute code under restrictive licensing terms to participate. - Hosting platforms inherit the risk of running third-party plugins. - EmDash’s sandboxing and permission model is positioned as a way to reduce reliance on centralized marketplace approval, though the provided article excerpt ends before explaining the promised “two important properties” in full. EmDash’s practical recommendation is to use capability-limited, isolated plugins as the foundation for a more secure and flexible WordPress-like ecosystem. Its early beta is intended for developers who want to evaluate that model on Cloudflare or Node.js.

Read original(opens in new tab)

Database DesignOpen SourceTypeScriptNode.Js+4

line·Apr 1, 2026·6 min readCurated summary

How did we build a domain-independent chat platform?

MessagingHub turns chat into a reusable platform rather than rebuilding it for each product domain. It separates domain-specific authentication and business context from common chat capabilities, allowing chatbot, customer-support, direct, and group conversations to share the same infrastructure. Its policy-driven design, modular architecture, and configurable metadata aim to reduce integration complexity while preserving flexibility. ## Why MessagingHub Was Introduced - Chat requirements vary across chatbots, customer support, one-to-one conversations, and group chats. - Building each implementation independently increases integration points, system complexity, development cost, and the impact of small changes. - MessagingHub is designed as a domain-independent platform that can be adopted by multiple services. - The platform focuses on chat itself while absorbing external requirements through generalized, reusable structures. - It is currently used by a Japanese food-delivery service for users, drivers, customer-service agents, and restaurants. ## Supported Chat Types - **Chatbots:** Delivered through a public web URL embedded in a partner service’s webview. Scenarios are created and deployed through an administrative console. - **Inquiry chat:** A user is matched with a customer-service agent. The partner domain supplies contextual information such as user details and previous consultation history. - The platform is also structured to support direct one-to-one and group conversations. ## Core Platform Policies ### Authentication and User Identification - MessagingHub does not manage user accounts or domain authentication. - Partner systems handle login, registration, permissions, and the decision of whether a user may access chat. - After authenticating a user, the partner requests a connection token and passes it to the client. - The client uses the token to establish a WebSocket connection; unauthenticated direct access is not allowed. - A user is identified by a `client_id`, combining the partner domain identifier with the partner’s user identifier. - Display names, profile images, and `pushToken` values are supplied and updated by the partner system. ### Service Contexts and Room Types - A **service context** defines which roles may communicate, such as: - `Driver2CS` - `Consumer2CS` - A **chat room type** defines the conversation structure, such as: - `USER_DIRECT` - `USER_GROUP` - `INQUIRY_CHATBOT` - `INQUIRY_CHAT` - The combination of service context and room type controls room creation, participation, and message permissions. ### Room Lifecycle and Data Retention - General room states progress from `WAIT` or `PENDING`, to `SERVICE`, and eventually to `DISABLE` or `BLOCK`, where sending messages is prohibited. - Messages and potentially identifying data are encrypted at rest. - Data can be deleted immediately when all participants leave a room. - Partners can also configure retention periods for automatic deletion of older data. ## Modular Architecture MessagingHub is not a monolithic chat server. Its components have clearly separated responsibilities and communicate through loosely coupled events. - **`connection-manager`** - Manages WebSocket connections and validates connection tokens. - Tracks user connection status. - Helps identify active chatbot scenario connections during `SOFT STOP` processing. - **`chat-app`** - Implements core chat logic, including message delivery, room creation, state transitions, and read status. - Exposes functionality as commands that can be combined for different chat types. - **`message-router`** - Determines where recipients are connected. - Routes messages from the chat server to the appropriate connection-management component. - **`notification-app`** - Sends push notifications when recipients are offline or the application is in the background. - Uses partner-provided `pushToken` values and room-level notification settings. - **`admin-hub`** - Manages chatbot scenario editing and deployment. - Handles agent accounts, roles, service contexts, events, webhooks, monitoring, and statistics. ## Command-Based Chat Flows - Chat behavior is modeled as composable commands. - Common commands provide functionality shared across chat types. - Chatbot and inquiry-chat features add more specialized commands. - This “building block” approach allows business requirements to be assembled without creating a separate chat implementation for every domain. ## Data Model MessagingHub separates operational data from core chat data: - **`chat` database:** Stores users, rooms, participants, metadata, and messages. - **`chat_operation` database:** Stores operational and administrative information. Important entities include: - `chat_user`: Uniquely identifies users by `client_id`. - `chat_room`: Represents rooms and enforces room uniqueness at the schema level. - `chat_member`: Connects users to rooms. - `chat_room_meta`: Stores participant-specific state, including read position, push settings, input restrictions, and room status. - `chat_log`: Stores encrypted messages in a one-to-many relationship with rooms. - `prev_chat_log_id` preserves message ordering. - Room-level first and last message IDs, together with participant read positions, support unread-count calculation. - Partner metadata such as `system_data`, `search_data`, `user_details`, and `descriptions` is stored as JSON. MessagingHub preserves and forwards it without interpreting its domain meaning. - Scheduling, event, and webhook history are tracked through tables such as `chat_schedule`, `chat_event_record`, and `webhook_event_record`. - `service_context`, `chat_event`, and `webhook` configure allowed role relationships, event-message policies, and webhook behavior. ## Chatbot Scenario Management ### Flexible Scenario Structure - Administrators manage multiple chatbot scenarios through an editing tool. - Scenarios define messages, selectable options, and answers. - Webhooks can dynamically generate response content. - The hierarchical data model supports a broad range of chatbot flows. ### Version Deployment and `SOFT STOP` Chatbot scenarios transition through: `WAIT → SERVICE → SOFT STOP → DISABLE` - A newly deployed scenario becomes `SERVICE`. - The previous scenario moves to `SOFT STOP`. - Existing users can finish conversations using the previous version. - New users are directed to the latest scenario. - A scheduler periodically checks whether any users still have active connections to the old scenario. - Connection information is collected from connection-management servers and stored in a shared resource. - Once no active users remain, the old scenario is disabled and the scheduler stops. - This provides backward compatibility without disrupting users during deployment. ## Inquiry Chat Metadata and Lifecycle ### Partner-Defined Metadata Inquiry chat allows partner domains to provide information that helps agents handle cases effectively: - Search data for finding conversations - User details shown to agents - Custom display data - Event data for surveys or webhooks - Basic consultation descriptions - Room settings such as room names and push-notification titles - Tracking data for identifying and mapping rooms in partner systems ### Room Lifecycle Inquiry rooms generally move through: `PENDING → SERVICE → DISABLE → BLOCK` - `PENDING` represents the period while the user waits for an agent match. - `SERVICE` is the active consultation period. - `DISABLE` indicates that the consultation has ended. - `BLOCK` prevents further messaging after closure. MessagingHub’s overall approach is to keep the platform’s responsibilities narrow and reusable while allowing partner domains to own authentication, user meaning, and business-specific metadata. For organizations supporting multiple chat scenarios, a policy-driven, command-based platform with separated components and explicit data ownership can significantly reduce duplication and integration risk.

Read original(opens in new tab)

Database DesignMicroservicesJsonChatbot+4