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
Navigating Regional Network Blocks
Supabase describes how regional network blocks disrupted access to its multi-tenant developer platform and shares three incidents from September 2025 through March 2026. It explains that DNS-level or transport-layer blocking can affect every tenant when projects share domains and IP addresses, while adding a hosting domain to the Public Suffix List provides only partial mitigation. In the UAE, a project distributing unauthorized streaming content triggered an approximately 18-day block that ended after removal and engagement with the TDRA. Yemen saw TCP connections dropped for about eight days with no official explanation, while India’s roughly eight-day restriction was rescinded after project enforcement and technical engagement with MeitY. The post says providers should build regulator contacts, strengthen abuse response pipelines, and develop alternatives such as proxy domains, custom domains, and other workarounds.
Top 10 best practices tips for ClickHouse
ClickHouse delivers rapid analytical queries across massive datasets, but suboptimal schemas and queries can significantly reduce performance and storage efficiency. Aligning table definitions with ClickHouse storage and execution mechanics resolves these bottlenecks. Key practices include placing low-cardinality columns first in the ORDER BY clause to enable granule pruning, and selecting optimal data types while avoiding Nullable wrappers to cut memory overhead. Developers should treat partitioning as a data management tool for TTL drops or merge engines rather than a generic speed booster, preventing fragmented parts from slowing query execution. Recent improvements like the Analyzer query planner have also made joins viable, though dictionaries remain faster for static lookups.
Beyond A/B Testing: Using Surrogacy and Region-Splits to Measure Long-Term Effects in Marketplaces
Lyft describes a framework for estimating long-term effects of pricing and incentive decisions in its two-sided marketplace, where direct and market-mediated consequences can diverge. The method first uses residualized observational regressions to estimate how policy changes alter distributions of negative experiences such as wait times, surge, cancellations, idleness, and hourly earnings, validating those responses with switch-back experiments. It then applies Augmented Inverse Probability Weighting to estimate how these experiences affect future outcomes, summarizes the relationship with a surrogacy index, and checks calibration using user-split experiments. Finally, Lyft combines mediated and separately estimated direct effects and uses region-split experiments for end-to-end validation, selecting treated and control regions with a forward-selection algorithm inspired by FDiD. The framework is intended to support scenario planning, budget allocation, and continuous calibration of long-run marketplace forecasts.
ClickHouse is data lake ready
ClickHouse announced expanded data lake capabilities, enabling direct querying, accelerated ingestion into MergeTree, and writes across Apache Iceberg and Delta Lake tables. Open lake architectures provide storage portability across cloud providers and catalogs, but standard query engines often struggle with latency for real-time workloads. Over two years of development, ClickHouse engineered a native Parquet reader with page-level parallelism, integrated the Delta Rust Kernel, and introduced support for schema evolution, time travel, and DML operations. The platform functions across AWS Glue, Unity Catalog, Polaris, and Iceberg REST Catalog on storage systems including Amazon S3, Google Cloud Storage, and Azure Blob Storage. These enhancements allow organizations to execute federated, high-concurrency SQL queries across multiple catalogs or write processed analytical results back to their lakes without vendor lock-in.
Intelligent security at ClickHouse speed: How Cogent Security built an AI-native vulnerability management platform
Enterprise security defenders face shrinking exploitation windows alongside massive volumes of vulnerability findings across disconnected tools. To overcome query bottlenecks from traditional relational databases, Cogent Security designed a lakehouse serving architecture using Apache Iceberg and per-customer ClickHouse instances. The architecture relies on query-driven denormalized tables, custom compression codecs, and pre-computed projections to serve hundreds of millions of rows with sub-second latency. On top of this data layer, Cogent implemented an agentic text-to-SQL system that iteratively queries live data, references an in-house Ontology Service for semantic context, and applies majority-voted evaluations. This combination improved text-to-SQL accuracy from 40% to 94% while providing sub-three-second response times across 98.7% of queries at 100 million rows.
Smarter Auto-Scaling for ClickHouse: The Two-Window Approach
ClickHouse Cloud required a vertical auto-scaling mechanism that preserves rapid scale-ups while avoiding prolonged over-provisioning after traffic drops. Operating on a single 30-hour lookback window forced scale-downs to take up to 30 hours, whereas an earlier fixed-factor CPU algorithm caused severe oscillations. The engineering team deployed a dual-window recommender pairing a 3-hour window for responsive scale-downs with a 30-hour window for single-step scale-ups. Alongside a trend-based hunting check to resolve conflicting window recommendations, the team introduced target-tracking CPU scaling using geometric mean watermarks and 10-minute median smoothing. This dual-window architecture reduced scale-down latency to 3 hours, prevented scaling oscillations, and significantly reduced infrastructure costs for variable database workloads.
Building high-performance full-text search for object storage
ClickHouse redesigned its native full-text index to address latency bottlenecks caused by random read patterns on remote object storage. Instead of using a Finite State Transducer dictionary, the new architecture organizes indexed tokens into fixed-size sorted blocks compressed with front-coding. Each data part separates index data across a small in-memory sparse index file, a sequential dictionary file, and a posting list file. This layout allows the query engine to pinpoint token locations with minimal random I/O and resolve multiple full-text functions directly from index files. Consequently, ClickHouse Cloud maintains predictable search latency across shared object storage while matching local disk performance and scaling through parallel query execution.
Making Ads Count: Using MMoE and Auxiliary Tasks to Better Connect Buyers & Sellers
Etsy’s Ads Search ranking model needed a stronger purchase-intent signal because clicks are noisy and purchases are sparse later in the buyer journey. It retained its shared feature-representation and interaction layers, then replaced the shared feed-forward network with Multigate Mixture of Experts (MMoE), using task-specific gates and towers for click-through rate (CTR) and post-click conversion rate (PCCVR). Add-to-cart was added as an auxiliary task, while favorites were rejected after producing negative transfer. Offline, the resulting model increased Purchase and Click PR AUCs by average 3.5% and 1%, respectively, and Purchase ROC AUC by 0.5%. Online, it improved purchases and purchase calibration, supplied better inputs to auto-bidding, kept model size flat through pruning, and reduced inference cost.
How Slack Rebuilt Notifications 📣
Slack redesigned its legacy notification architecture to address user confusion, conflicting desktop and mobile preference systems, and tight coupling between notification content and push delivery. The engineering team unified four separate preference models into a single framework with three channel options: All new posts, Mentions, and Mute. To ensure safe rollback and backwards compatibility without direct database mutations, Slack implemented a read-time translation strategy alongside a new desktop_push_enabled preference and auto-saving cross-platform React UI components. This decoupling of activity from push delivery resulted in a fivefold sustained increase in settings engagement, reduced reliance on per-channel overrides, and eliminated synchronization mismatches across mobile and desktop clients.
Building a Magic Mirror: AI retail experiences with Remix
Shopify’s “magic mirror” is an AI-powered retail installation that uses a display and hidden webcam to deliver personalized messages, animations, and product interactions in under a minute. A Remix route handles the browser and server boundary: a button-triggered POST captures an image, sends it with a curated prompt to a vision-capable language model, and renders a compliment plus a makeup recommendation; server-sent events optionally let a remote device trigger or reset the experience. The prompt combines persona and safety constraints, a plain-text product and inventory table, and a required JSON schema, while strict product-ID lookup provides graceful degradation. The interface uses explicit states, delayed capture, timed response and reset screens, and animated transitions. The production setup keeps brand configuration, shared components, actions, and SSE infrastructure reusable across mirror modes.
How ClickStack makes ClickHouse faster for observability
ClickHouse delivers high performance for telemetry data, but unoptimized queries on high-cardinality observability workloads can bypass pruning, inflate intermediate state, and exhaust cluster resources. ClickStack addresses this challenge by embedding engine-specific optimization best practices directly into how queries are generated, structured, and executed. For search workflows, the platform executes progressive queries across bounded time windows using optimize_read_in_order to return initial rows rapidly without scanning entire historical ranges. ClickStack also segments large chart aggregations into parallel bucket-aligned queries, automatically redirects map attribute filters to pre-materialized columns, and extends lazy materialization thresholds to minimize runtime input-output overhead. These query formulation strategies are being packaged into specialized analytical endpoints to power notebooks and external tools without requiring manual SQL tuning or exposing raw database interfaces.
How Socialpruf built a faster, more reliable data stack by replacing Neon with Postgres managed by ClickHouse
Socialpruf, a social media performance tracking platform ingesting hundreds of posts per second, experienced analytics latency, connection dropouts, and high network transfer costs while running Postgres on Neon alongside ClickHouse Cloud. To resolve these issues, the team migrated their transactional system of record to NVMe-backed Postgres managed by ClickHouse, colocating transactional and analytical workloads. Although standard Postgres logical replication failed on their 0.5 TB dataset, they achieved continuous synchronization using PeerDB before conducting a production cutover. The migration eliminated connection dropouts, reduced network transfer fees, and improved overall Postgres query performance by approximately 30 percent. To manage thousands of concurrent connections generated by ingestion workers, Socialpruf implemented ClickHouse's bundled, horizontally scalable PgBouncer instances.
AI is redrawing the database market
Emerging artificial intelligence workloads are fundamentally transforming data platform requirements across real-time analytics, data warehousing, and observability. Conversational analytics and autonomous agents replace periodic batch queries with rapid bursts of concurrent, low-latency requests, exposing the architectural limits of traditional cloud data warehouses and standalone transactional databases. To resolve these constraints, architectures are converging on engine-level integrations between Postgres for transactions and ClickHouse for analytical scale, while unifying operational observability and business event storage. ClickHouse also incorporates turnkey agent interfaces through its acquisition of LibreChat alongside dedicated execution tracing from tools like Langfuse. These combined capabilities ensure organizations can reliably support interactive agentic workflows without incurring severe latency penalties or compounding infrastructure costs.
Designing the new async-native ClickHouse Python client
The official ClickHouse Python client, clickhouse-connect, originally addressed asynchronous execution by wrapping its synchronous HTTP client in a thread pool executor. However, this executor model experienced thread exhaustion, GIL contention, and severe tail latency variance under heavy concurrent workloads. To resolve these scalability bottlenecks, the developers redesigned the client around a half-sync/half-async pattern utilizing aiohttp for async network I/O. A custom bounded queue bridges streaming socket reads on the event loop with synchronous, CPU-intensive binary parsing running inside background threads. Benchmarks demonstrate that this architecture stabilizes tail latencies, delivering an average P95 latency of 556 milliseconds compared to 869 milliseconds for the legacy executor client.
AI doesn’t always generate perfect ClickHouse schemas (yet)
LLMs can generate syntactically valid ClickHouse schemas whose advanced choices are poorly matched to a workload. The post examines recurring pitfalls including query-driven partitioning, per-column codecs, premature projections, materialized-view sprawl, JSON configurations, and forced deduplication with OPTIMIZE TABLE ... FINAL. It explains that partitions primarily support data management, incremental materialized views add work to every insert, and ReplacingMergeTree deduplicates during background merges rather than at insertion. The recommended method is to begin with a simple MergeTree or ReplacingMergeTree, a well-chosen ORDER BY, default compression, and no optional structures, then measure production behavior before adding complexity or seeking human expertise for high-scale, interconnected designs.
Shopify’s journey to faster breadth-first GraphQL execution
Shopify describes how high-cardinality, deeply nested GraphQL queries exposed execution overhead beyond data loading, with field resolvers assembling responses consuming much of request time. Its GraphQL Cardinal engine replaces conventional depth-first traversal with breadth-first execution, resolving each selected field once across an aggregated set of objects and reducing repeated field-level work. For large list queries, Shopify reports up to 15x faster execution, 90% less memory use, and reductions of many seconds in P50 latency. The migration included a tuned interpreter, cheaper tracer behavior, shadow verification, benchmarks, and ongoing conversion of tens of thousands of legacy resolvers, while future work includes asynchronous patterns and lower-level C bindings.
Announcing chDB 4: write Pandas, run ClickHouse, now on Hex
chDB 4 introduces Data Store, a native component that allows users to write Pandas-like code that executes on the ClickHouse OLAP SQL engine. Standard Pandas workflows suffer from eager execution, excessive memory materialization, and lack of automatic query optimizations. To solve this, Data Store implements a four-layer architecture that lazily records operations as a chain of LazyOp objects and compiles them into optimized ClickHouse SQL plans upon evaluation triggers. When encountering operations unsupported by ClickHouse, the QueryPlanner splits the pipeline into segments, routing tasks between ClickHouse and Pandas while using Python's memoryview to minimize data copying overhead. This release also integrates natively into Hex notebooks.
Keep the Tokens Flowing: Lessons from 16 Open-Source RL Libraries
At-scale reinforcement-learning training is constrained by long, variable data-generation workloads that leave training GPUs idle, especially for reasoning and agentic models. The surveyed architecture separates inference and training onto distinct GPU pools, connects them through a rollout buffer, and synchronizes weights asynchronously so both stages can proceed concurrently. Sixteen open-source libraries are compared across orchestration, buffering, weight synchronization, staleness, partial rollouts, LoRA, and distributed backends; Ray appears in 8 of 16 orchestration implementations, while NCCL broadcast is the default weight-transfer method. The proposed TRL async trainer favors a lightweight bounded queue with per-token model_version metadata, packed NCCL transfers, and experimental support for prefix-resume or abort-and-retry handling of rollouts interrupted by weight updates.
What Replo learned optimizing 100+ billion events in ClickHouse
Replo built an analytics pipeline on ClickHouse to serve more than 4,000 Shopify merchants processing 3,000 to 5,000 events per second. The initial single-table architecture recalculated session metrics on the fly, leading to poor query efficiency as volume scaled. To speed up dashboard queries, the team implemented a mark-and-unmark pattern with SummingMergeTree and refreshable materialized views, but real-time deduplication and fractional attribution caused runaway query backlog loops. Replo resolved the issue by limiting real-time recomputations to a specialized table holding only the last 40 minutes of purchase-related events. This architecture allowed processing over 100 billion records while keeping query times fast and ingestion lag to approximately one minute.
Ulysses Sequence Parallelism: Training with Million-Token Contexts
Ulysses Sequence Parallelism addresses the memory and compute pressure of training language models on sequences extending beyond tens of thousands of tokens, where attention remains quadratic in sequence length even with FlashAttention. It shards tokens across GPUs, projects local queries, keys, and values, then uses two all-to-all operations to exchange data so each GPU computes a subset of attention heads before restoring sequence-sharded outputs. The post describes integrations with Accelerate, the Transformers Trainer, and TRL's SFTTrainer, including variable-length handling and weighted loss aggregation for uneven valid-token counts. In reported four-GPU tests, SP=4 reduced per-GPU memory sufficiently for 96K-token training on H100 80GB GPUs, reached 13,396 tokens per second at 64K, and matched non-SP canonical token-normalized loss within 0.000005 maximum absolute difference.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.