API Versioning as a Translation Layer
API versioning as an architecture: requests enter through a version header, pass through a chain of reversible version changes, and reach controllers that only ever see the latest model.
Loading…
Topic
Architecture
830 posts about Architecture. Every summary links to the original.
- 830 posts
- 50 companies
- 31 explainers
See the idea
Architecture explainers
BIAN as a Contract Layer: Modernizing Core Banking One Domain at a Time
BIAN gives banks a shared vocabulary and service-domain contracts that sit between business concepts and the systems implementing them. See how domains, contracts, and governed access stack into one architecture.
Argo CD: The Reconciliation Loop Between Git and Your Cluster
Argo CD is a GitOps controller that treats Git as the desired state and continuously reconciles it against what actually runs in each cluster. It maps the parts of that loop and why pull-based agents change its scale.
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Posts
amazon.science
Navigating uncertainty in Amazon's middle-mile network
Amazon's middle-mile logistics network coordinates tens of millions of packages across hundreds of facilities while managing subtle demand variations and major operational disruptions. To solve this mixed-integer optimization challenge without combinatorial explosion, Amazon models routes at coarse time resolutions augmented by precomputed 15-minute timing bounds. The system uses Monte Carlo methods alongside a graph attention network featuring interconnected site graphs and origin-destination graphs to capture complex spatial correlations and flow interdependencies. By generating synthetic flow permutations, planners stress-test candidate network designs against hundreds of plausible scenarios to prioritize routing optionality. This risk-aware modeling approach preserves network flexibility, absorbs severe shocks, and yields potential cost savings while safeguarding delivery promises.
Agentic analytics starts with query-ready data: the write-side cost of Snowflake vs. ClickHouse
Agentic analytics workflows introduce bursts of concurrent, low-latency analytical queries over continuously ingested data. Analytical query efficiency relies on columnar storage and chunk-level pruning, which require contiguous, sorted data to avoid full-table scans. Rather than evaluating warehouses solely at query runtime, this benchmark compares the write-side cost of maintaining query-ready data in ClickHouse and Snowflake during continuous ingestion at approximately one million rows per second. Snowflake relies on post-write clustering to organize data, whereas ClickHouse constructs sorted layouts on the write path and refines them via background merges. Across 100B, 200B, and 300B row checkpoints on the ClickBench dataset, ClickHouse achieved a query-ready layout at 22 times lower cost and delivered 28 times better write-side cost-performance.
The AI scaling gap hiding in digital native companies
An Economist survey of 1,220+ executives across eight industries finds that digital native companies lead in ambition and breadth of AI deployment, but not in full operational maturity. At 18%, they are the most likely group to prioritize embedding AI across core processes at scale, and nearly 92% report AI ROI ahead of plan. Yet they lead fully embedded AI—defined as use by 100+ users, SLAs, and performance and impact monitoring—in only one of eight functions, R&D/product development; they rank seventh in finance and sixth in operations and supply chain. Telecom, media and entertainment, manufacturing, and energy outperform them in selected functions despite lower stated scaling priority. The proposed response is to build shared, production-grade foundations for data, governance, workloads, models, agents, and applications, with security, lineage, monitoring, and performance measurement treated as reusable capabilities.
How nOps rebuilt their cloud optimization platform on Databricks Lakebase, and why other ISVs should too
nOps migrated its production cloud optimization platform to Databricks Lakebase, a fully managed PostgreSQL database integrated with the Databricks Lakehouse. Its previous setup separated customer-facing operational data from analytics, requiring scheduled jobs, cron-based change-detection logic, and synchronization work that introduced lag and operational overhead, especially as workloads expanded to GCP and Azure. In the new architecture, Lakebase is the central Postgres database and single source of truth for the front end and AI infrastructure, while the Lakehouse continuously consumes its data for analytics and metric computation. Databricks Metric Views are automatically surfaced in the application, and data flows one way without direct write-back. The reported results are faster data pipelines, lower operational overhead, and a better customer experience, with auto-scaling, auto-stop, restore, OAuth, and compatibility features supporting adoption.
From SSH to REST: A Security-Driven Modernization of Slack’s EMR Data Pipelines
Slack's data platform accumulated over 700 SSH-based Airflow operators executing jobs directly on AWS Elastic MapReduce clusters, creating broad security surfaces and operational instability. Stateful SSH connections frequently failed when Kubernetes pods restarted, leaving orphaned zombie processes and preventing infrastructure modernization such as migrating EMR clusters to child accounts. To eliminate SSH access, Slack adopted a REST-based architecture using Quarry, a gateway providing unified REST APIs and token authentication across compute engines. For non-Hadoop CLI workloads, Slack leveraged YARN Distributed Shell to execute arbitrary shell scripts stored in Amazon S3 within managed, isolated YARN containers. The phased migration achieved zero downtime across eight data regions, unlocking reliable monitoring, simplified onboarding, and future initiatives like Spark on Kubernetes.
amazon.science
How mechanism design theory helps optimize Amazon-vendor collaboration
Amazon and its vendors face an asymmetric information problem when coordinating purchase orders across fulfillment centers because neither party shares proprietary cost, capacity, or demand data. To solve this coordination gap without exposing sensitive information, Amazon's Supply Chain Optimization Technologies organization designed Flo Pro by integrating the Vickrey-Clarke-Groves mechanism with the Consensus Planning Protocol. The distributed optimization framework uses the alternating-direction method of multipliers to coordinate iterative agent responses, calculating cost-benefit transfers across rolling six-week planning horizons. In lower-dimensional settings, Amazon also evaluated a transparent menu-of-contracts approach where vendors select optimal plans priced at Amazon's incurred costs. A nine-week pilot with a consumer-product manufacturer confirmed that Flo Pro successfully aligns incentives and achieves measurable cost savings.
The 5 Layers Every Cloud Commitment Depends On
Long-term hyperscale cloud commitments are presented as distributed-systems problems with expensive consequences when physical assumptions are wrong. The post proposes a dependency sequence across regional and availability-zone topology, power architecture, fit-for-purpose compute, SKU qualification, and network design. It compares application-observable latency with bare-metal RTT, uses power consumption as a migration check, and argues that workload characteristics should drive memory-to-core ratios, silicon generations, instance families, and routing choices rather than provider defaults. It also explains why zone placement, inter-zone and inter-region transfer, and egress pricing affect quorum latency, reliability, and economics, while noting that cross-region traffic may require explicit justification. The conclusion is that these constraints compound over the commitment unless teams manage architectural drift, with software and contracting layers addressed separately.
The foundation of AI scalability: One team, one platform, one operating model
Albertsons Companies describes a centralized AI strategy for scaling decisions across merchandising, labor, supply chain, and customer experience across approximately 2,300 stores. The model combines one central AI core, the Databricks Data + AI Platform, and a shared operating model spanning data engineering, ML, governance, and analytics. Reusable ingestion pipelines, templates, feature-store patterns, model monitoring, performance observability, and governance wrappers support local execution, while a company-wide governance committee sets shared standards. Albertsons reports accepting 1.38 million lines of AI-generated code in nine months, with more than 90% of engineers using AI tools, and it provides low-code dashboards, prompt libraries, and conversational agent generation for nontechnical teams. Success is measured through reuse rates, time to deployment, responsible AI compliance, and business outcomes linked to AI uplift, with initiatives required to demonstrate impact before scaling.
Agentic identity: modeling agents to keep users in control
Ramp for Agents adds CLI and MCP interfaces through which AI agents can manage cards, bills, expenses, and approvals, creating a need to represent agents as accountable actors instead of handing them users’ session tokens or API keys. The initial identity model links a named Agent Key to a human sponsor and business, bounds scopes by the sponsor’s role, records agent attribution, and adds expiration and revocation. Ramp extends RBAC and its DenormalizedActor audit model with AgentContext, so logs, approvals, and webhooks can distinguish “Sarah (via Codex)” while reusing existing permissioning and rendering paths. OAuth2-PKCE exchanges the Agent Key for short-lived access and refresh tokens, with re-validation during refresh to limit leaked-credential exposure and preserve session traceability. The first release uses on-behalf-of-user agents because they fit current demand and keep a human accountable, while admins can oversee keys or disable agent access for roles and groups.
Learnings from init to deploy
An agent was used to build a transcription app for a team from initialization through deployment with Stripe Projects, OpenRouter, and Vercel. The app sends video-generated subtitles through an OpenRouter agent with a detailed system prompt and Stripe documentation tool calls, producing a formatted transcription whose speaker and service names are corrected. The author recommends treating agent-generated plans like design documents, verifying provider behavior, and using streaming for long transcripts because Vercel serverless limits made non-streaming responses prone to 504s for a roughly 1,500-line transcript. Testing led to removing an unreliable free-model tier, defaulting to openrouter/auto, and choosing Claude Opus 4.5-thinking over Claude Sonnet 4.5; shared agent files were committed, and a separate review agent was used before human review.
Optimizing ML Workload Network Efficiency (Part I): Feature Trimmer
Pinterest deployed a root-leaf architecture for online machine learning serving to decouple CPU-based feature preprocessing from GPU-based inference. Because the root cluster retrieved a union of features across models and fanned out the full set to every leaf, network bandwidth became a severe bottleneck. After initial tests with fbthrift LZ4 compression yielded a 20% bandwidth reduction at the cost of CPU and latency overhead, the team implemented Feature Trimmer. This mechanism uses exported model signatures as the source of truth to prune unused features on the root before transmission. By dispatching only required features per model, the system reduced network bandwidth, decreased latency, and enabled cluster rightsizing that saved over $4M annually.
Database modeling: a practical guide to techniques and best practices
Database modeling defines the structure, relationships and constraints that keep systems coherent across transactional, analytical and flexible workloads. The guide presents a three-phase design process: conceptual modeling captures entities and relationships, logical modeling adds attributes, keys, cardinality and normalization, and physical design translates that model into tables, indexes, constraints, partitioning and other platform-specific choices. It compares relational, document/NoSQL, dimensional, hierarchical and network models, linking each to data shape, workload and consistency requirements. It recommends explicit keys, consistent naming, appropriate normalization, query validation and version-controlled DDL, while warning against premature physical design, missing foreign keys, unclear NULL handling and poorly balanced schemas. It concludes that Databricks Lakebase combines a transactional database engine with the Databricks Lakehouse Architecture so one model can support operational and analytical workloads.
Goodbye limitations, hello data: How Qonto is rethinking observability with ClickHouse Cloud
Qonto struggled with slow queries, system instability, and aggressive data sampling when handling distributed traces in Grafana Tempo. To enable wide-event querying without strict cardinality limits, the team migrated their telemetry storage to ClickHouse Cloud. Telemetry from applications, Kubernetes, and GitHub routes through OpenTelemetry collectors over AWS PrivateLink into ClickHouse, while Grafana remains the primary dashboard interface. By compressing 231 TB of uncompressed trace attributes down to 376 GB, Qonto achieved substantial storage savings and integrated an AI incident companion using the ClickHouse Model Context Protocol. The new architecture eliminated cardinality policing, allowed product and support teams to self-serve incident investigations, and enabled real-time streaming pre-aggregations using Apache Flink.
Ready, Set, Build with the NHS Federated Data Platform
The NHS Federated Data Platform (NHS FDP), delivered by NHS England through a consortium led by Palantir, connects operational data held in separate NHS systems while keeping each organisation’s data under local control. Built on Palantir Foundry, its federated tenants use the Canonical Data Model, encryption, purpose-based access, and Privacy Enhancing Technology for national data flows. As of end December 2025, the post reports 110,078 additional theatre procedures, 797,728 patients safely removed from waiting lists, and 297,943 safely discharged patients, alongside around a 15% reduction in observed discharge delays. The inaugural Build with FDP hackathon brought together over 120 NHS developers and analysts, who built 25 working prototypes on a notional Canonical Data Model to address frontline operational challenges. Projects included early-warning, bed-demand prediction, CAMHS demand balancing, and genomic-optimised waitlist tools.
Agents are ready, but your architecture probably isn't
Enterprise AI initiatives often produce activity rather than value because organizations start with technology instead of a defined outcome and overlook data architecture, governance, and semantic context. Agentic systems add risk when they can send messages, update records, place orders, or delete records, making permissions and situational controls essential. The discussion argues that dashboards and batch pipelines are poorly matched to low-latency, high-scale agent workloads, which require transactional infrastructure alongside existing analytics. Lakebase is presented as that transactional foundation, while AgentBricks, Databricks Apps, and Genie provide agent development and monitoring, application delivery, and conversational data access. The recommended path is to define success first, isolate a focused pilot, learn what works, and redesign underlying processes rather than merely add AI to them.
uAct - Unified Action Platform
Uber built uAct to consolidate action items and approval requests generated by its many internal applications, addressing notifications that could be lost among email and follow-ups. It combines real-time fetching with scheduled offline ingestion through Apache Camel, stores requests, and merges them in received and sent views. Users can act through deep links or within uAct, where the Action Dispatcher authenticates and authorizes actions and the Audit Trail Provider records them for compliance. Its onion-architecture backend uses orchestrators, application-specific mappers, MySQL for requests and CacheFront for preferences, while parallelized paginated calls and strict timeouts support performance as integrations grow. The platform has been implemented across Uber and also provides configurable views, hiding, manager filters, observability, privacy controls, and planned Slack notifications, reporting, nudging, and additional integrations.
Connecting Agents to Decisions
Palantir’s Ontology is presented as a decision-centric architecture for human-agent operations, intended to represent how enterprises make and execute decisions rather than only storing or analyzing data. It combines data, logic, action, and security in a shared, dynamic representation that can connect operational data, computational processes, workflow execution, and policy controls. The data layer includes structured, streaming, edge, unstructured, imagery, and decision data, with decision lineage recording the data version, application, and decision context; logic binding connects heterogeneous business, modeling, planning, and optimization assets for human and agent workflows. The architecture exposes approved actions to agents with configurable human review and guardrails, while capturing decisions as learning material for improving workflows and agentic memory. It concludes that a real-time ontology can anchor AI in enterprise conditions while controlling where automation is allowed.
From Clicks to Conversions: Architecting Shopping Conversion Candidate Generation at Pinterest
Pinterest built a dedicated shopping candidate generation model to optimize for lower-funnel purchase conversions rather than relying strictly on engagement retrieval models. Because offsite conversion events are sparse and delayed, engineers trained a single multi-surface two-tower model using conversion data supplemented by duration-weighted click engagement and unengaged ad impressions as hard negatives. The two-tower retrieval architecture incorporates a parallel DCN v2 and MLP layer structure that allows simultaneous learning from the same inputs without information bottlenecks. Later revisions transitioned the system from a multi-head loss structure to a unified single-head multi-task architecture paired with an advertiser-level objective. Deployed across more than 600 million monthly active users, the system increased shopping conversion volume by 2.3% and boosted return on ad spend by 3.1% for United States shopping campaigns.
ClickHouse at Google Cloud Next '26
ClickHouse announced several product updates and integrations designed to deepen native compatibility with Google Cloud. Migration of ClickHouse Cloud to Google Axion ARM-based processors demonstrated a 30 to 55 percent query speed increase and reduced data load times from 64 to 26 seconds on ClickBench benchmarks. An integration with Google Lakehouse Runtime Catalog enables querying Iceberg tables on Google Cloud Storage via the DataLakeCatalog engine without data movement. Furthermore, Bring Your Own Cloud reached general availability on Google Cloud Marketplace, and ClickPipes added an unordered mode using Pub/Sub notifications for GCS ingestion. Google Antigravity integrated ClickHouse through an MCP server to translate natural language into SQL and generate interactive React charts.
How to build scalable web apps with OpenAI's Privacy Filter
The article presents three web applications built around OpenAI’s open-source Privacy Filter, a PII detector that labels eight categories in one forward pass over a 128k-token context. Document Privacy Explorer extracts PDF or DOCX text and returns category-labeled spans, while Image Anonymizer combines Tesseract word boxes with character offsets to produce editable pixel redaction rectangles. SmartRedact Paste replaces detected spans with category placeholders, stores public and token-gated views, and evicts expired pastes in a daemon thread. Across the apps, gradio.Server’s @server.api routes model work through Gradio’s queue and gradio_client, while plain FastAPI routes serve custom HTML, views, and lightweight lookups. The implementations keep browser-side filtering, canvas edits, and PNG export out of server round-trips, and the paste service is about 200 lines including storage.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.