Loading…
Topic
834 posts about Architecture. Every summary links to the original.
See the idea
Amazon Bedrock is the managed reasoning tier in an agent architecture, not the whole system. This layered view shows the pipelines, governed tables, query layer, and guardrails around it.
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.
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.
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
Ridgeline, a cloud-native investment management platform, rebuilt its performance analytics layer after Postgres could not handle the scale of larger customers. The team evaluated Redshift, SingleStore, Trino over Iceberg, and a custom in-memory engine before choosing ClickHouse for its analytical performance and lower cost. They adopted ClickHouse Cloud on AWS, using separate organizations for staging and production and per-customer services, with assistance from ClickHouse engineers. Historical data lands in Apache Iceberg via a Spark pipeline and is queried through ClickHouse, while recent data is written directly into ClickHouse. The architecture enabled Ridgeline to serve customers 10x larger than before and more than double its live customer count.
eBay’s Monetization Team lacked a dedicated observability platform, causing fee behavior issues to often be discovered through customer complaints or post-transaction analysis. Data warehouse data arrived with delays, and engineers and business teams had to manually query multiple sources. Minerva solves this with an asynchronous observability pipeline: the fee-processing service places a small record on a local queue, a background producer publishes it to an event stream, and a consumer enriches the data before storing it in ClickHouse. ClickHouse’s columnar storage and MergeTree engine allow fast aggregation queries on records with nearly 250 columns; a proof of concept on 1.1 billion rows returned queries in 0.11 to 0.72 seconds. The design keeps observability off the critical fee path, prioritizing fee-processing availability while providing configurable, context-aware monitoring.
At Anthropic, Claude’s ability to iterate on code at high speed has caused git-based source control to become the bottleneck in their development workflow. To handle the growth from 2,500 to over 30,000 daily code merges, the team built Scion, an in-house version control system, fully migrating their monorepo from git in five months. Scion diverges from git by assuming clients are always online, shifting computation to the server, and using horizontally scalable data structures without any fully materialized copy of the repository. The system stores changes as entries in a write-ahead log, supports sparse and virtualized checkouts, and enables cheap, lock-free commits that scale with change size rather than repository size. Anthropic shares Scion’s design principles to help the broader ecosystem prepare for AI-driven scaling challenges, noting that similar pressure points will emerge for other organizations as AI coding tools become more common.
D1, Cloudflare’s serverless SQLite database, has seen 15x growth in live databases over the past year and scales by keeping query execution on the edge in Durable Objects, separate from the control plane’s metadata operations. The control plane uses an Edge API Worker with Hyperdrive to access Postgres clusters for transactional metadata, while Workers KV caches database-to-Durable-Object mappings for fast edge lookups. Database creation completes in about 1.6 seconds by generating a Durable Object ID, persisting metadata to Postgres, and storing the mapping in Workers KV, with the Durable Object lazily initialized on first query. Storage usage enforcement uses atomic counters in Workers KV that are checked locally on each query and updated asynchronously after execution, avoiding any central database round trip during the query. Precomputed aggregations for billing are stored in ClickHouse, and guiding principles such as eventual consistency and idempotency further reduce reliance on centralized components.
Level 5 covers operability for LLM systems: daily running, cost control, provider outage survival, and fast shutdown on misbehavior. A single gateway funnels all model traffic, measuring cost, routing requests, enabling failover, and hosting an instantaneous kill switch; a shared decision_id threads metrics, logs, traces, and the audit ledger. Observability supplements RED metrics with a decision layer capturing auto vs. human splits, guardrail blocks, judge disagreements, token spend per tenant and capability, and shadow-eval pass ratios via tiered structured logs. Cost controls attribute spending at the gateway per tenant and capability, with hard budget ceilings; optimization follows order: skip model, batch, cache, right-size, trim—each step profiled against quality. The platform spine includes stateless agent services, the gateway, an audit datastore, cache, secrets store, and object storage—scoped with least-privilege IAM and encryption, avoiding queues or vector stores until warranted.
To survive intense competition from copycats and dominant tech companies, software businesses must execute faster and more efficiently than their rivals. Run Less Software is a three-pillar philosophy that helps teams achieve this: choose standard, boring technologies to build deep expertise and reduce operational overhead; outsource undifferentiated heavy lifting like infrastructure to specialized third-party providers; and focus all engineering effort on creating enduring competitive advantage that directly serves customers. For example, Intercom consolidated from MongoDB and Postgres to AWS Aurora and DynamoDB, standardizing on MySQL and gaining 5x throughput at a 30% cost reduction with minimal custom code. By constraining the toolset, teams become expert operators who can make faster, cheaper decisions. The philosophy enables companies to manipulate time and stay ahead of competitors by systematically reducing the cost and risk of their engineering decisions.
The post introduces Level 1 of a six-level maturity model for production LLM systems, the determinism layer, which contains the model to a single node so the surrounding system is ordinary, testable code. The core design move is making the agent a pure function that proposes decisions without side effects, with a separate substrate that applies proposals only after approval. The system uses a fixed graph of nodes where the LLM is used only in one node for judgment, and all other nodes are deterministic, testable code. Structured output is enforced via schema constraints and validation, and confidence is composed from independent signals rather than taken from the model. For capabilities requiring autonomy, a bounded loop with a step cap and tool allow-list is used, but the default is the fixed graph to maintain predictability and auditability.
The Prime-Sentinel Command (PSC) architecture is an object-oriented master-agent pattern for coordinating edge diagnostic nodes via a centralized orchestrator. Many diagnostic setups tightly couple data polling with central processing, creating bottlenecks and complicating retry logic. PSC isolates agent-level diagnostics into self-contained SentinelProgram instances that sample CPU load, memory utilization, and network state flags, returning structured telemetry payloads. The PrimeProgram controller manages lifecycle dispatch, dynamic registration, batch execution passes, and reporting thresholds, using synchronous list comprehension for sweeps with notes on swapping to concurrent.futures.ThreadPoolExecutor or asyncio.gather for higher node counts. The reference implementation demonstrates three sentinels reporting metrics like CPU 24.15%, RAM 45.20%, and network status STABLE, with payloads designed for JSON serialization across WebSockets, gRPC, or message brokers.
On September 29th, MongoDB announced the public preview of Atlas Infinite, a new deployment option built on disaggregated storage where compute and storage run on separate machines. The shared storage layer consists of three services: a Log Service for write consensus, a Page Service keeping materialized pages warm, and an Object Index Service managing object storage. This architecture was necessary because WiredTiger’s speculative eviction and deferred writes made conventional approaches impossible. Data is encrypted on the compute node before reaching the storage layer, preventing shared services from reading documents. Benefits include unlimited storage scaling, read replicas without disk copying, and constant-time snapshots.
GitHub is rebuilding its Git infrastructure to handle agentic development, where agents push millions of commits daily and total activity doubled to 473.3 billion events per month. The current Spokes architecture couples durability with scale by storing full repository copies on local disks and using a quorum for writes, making writes slower as read replicas are added. Key challenges include commit turnaround latency per agent, write throughput up 4.9x year over year, merges contending on a single reference, and CI fan-out multiplying each push into thousands of reads. The new design separates storage from compute, using Azure Blob Storage for durability and lightweight workers for reads, shrinks the critical path by coordinating only reference updates, and moves maintenance off the serving path. Internal benchmarks show up to 35 times higher write throughput with independently scaling read capacity, while preserving existing workflows, branch protections, and audit controls.
Enterprise AI agents without persistent memory suffer from the “Groundhog Day” problem, repeatedly asking users to re-explain themselves. Agentforce Memory addresses this by giving agents persistent memory that retains user preferences, conversation history, and context across sessions. The team first established a shared terminology document to define concepts like semantic and episodic memory before architectural discussions could proceed. The architecture evolved incrementally, starting with conversation history injection and later adding semantic retrieval to find relevant past information regardless of recency. Memory retrieval uses keyword search during pre-orchestration to balance context quality with low latency, and moving memory into the Reasoner simplified configuration for administrators. Privacy and user trust were treated as architectural requirements from the start, enabling individual user controls over memory creation and management.
Traditional Postgres point-in-time recovery is slow because compute and storage are coupled, requiring provisioning a new instance, restoring a snapshot from object storage to disk, and replaying WAL, leading to hours of downtime for large databases. In a survey of developers running 1TB+ production Postgres, 59% had a critical production failure and 30% were down for over three hours. Lakebase Postgres decouples compute and storage using safekeepers, a pageserver, and object storage, storing database history as an immutable timeline. A restore becomes a branch at a point in history, a metadata operation that does not copy data, making it near-instant regardless of database size. This eliminates data copies and WAL replay, so restoring a 100 TB database is as fast as restoring 10 GB, and agents can use restores as ordinary tool calls for versioning and undo.
As agentic applications move from answering questions to taking actions, enterprises risk AI sprawl from duplicated integrations, inconsistent policies, and fragmented context. Databricks asserts scaling requires three pillars: choice across models and tools, context grounded in governed enterprise data and business semantics, and control through consistent permissions, policies, observability, and cost management. Its platform provides Agent Bricks for unified agent fleet building and governance, Omnigent as a common layer above agent harnesses, and Unity Gateway as a centralized control plane for models, agents, and tools. Context is shared via Unity Catalog for data and AI asset governance and Genie Ontology for common business concepts, letting teams reuse governed context across applications. Control uses Unity Gateway for access policies, budgets, and traces and Databricks Sandbox for isolated execution, with MLflow enabling evaluation and workflow inspection to maintain reliability as agents scale.
Data sovereignty is a market expression, not a universal legal standard, and IT leaders should evaluate it through architecture and governance questions rather than a single label. The assessment covers where data resides, who can access it, how it moves, and whether control is retained, with considerations varying by jurisdiction, industry, and risk posture. Physical location is only one part of a broader control boundary that includes operations, key custody, and access paths. The article proposes five technical lenses for evaluation: jurisdiction-native data placement, in-use encryption, customer-held keys, network isolation and identity-based access, and forensic-grade audit evidence. These lenses are practical reference points for architecture decisions, not a legal test or certification checklist, and organizations should assess their own requirements with qualified counsel.
Capital-markets firms are revisiting the trade lifecycle as data volumes grow, AI moves toward production, settlement cycles shorten, and scrutiny increases. Fragmented data across research, trading, risk, operations, and surveillance can slow decision-making, complicate execution analysis, limit risk visibility, and hinder reconstruction of events. The proposed response starts with decisions such as execution-cost divergence, shock impacts, and exception or settlement-fail rates, then identifies the data domains needed for a few high-value workflows rather than migrating everything at once. It emphasizes a governed, reusable foundation connecting real-time and historical data, analytics, and AI, with access controls, lineage, traceability, and evaluation. Databricks components named include Unity Catalog for governance, discovery, and lineage, Agent Bricks for domain-specific agents, and AI/BI for governed exploration; the stated conclusion is that this operating-model approach can support faster decisions, resilience, and scalable use cases.
Fizz.hu, an ecommerce marketplace backed by OTP Group, outgrew a Microsoft SQL Server and Power BI setup that relied on daily batch loads and separate virtual-machine Python workloads. The company migrated about 50 tables and several stored procedures to Databricks SQL, recreated core views, and moved to a lakehouse architecture using an MVP-first approach rather than redesigning everything. Completed in three months, the migration switched off SQL Server while keeping Power BI reports running on the new engine. Nightly processing fell from three to four hours to roughly 90 minutes, reports became consistently available by 4:30 a.m., Power BI refreshes dropped about 50%, and gigabyte-scale exports finish in minutes. Databricks now unifies SQL, Python, machine learning, governance work, and Hungarian-language Genie self-service, with about 20 users reclaiming roughly 20% of an analyst’s time.
Memory scaling is proposed as an agent’s performance improving when it accumulates past conversations, feedback, interaction trajectories, and business context in persistent external memory. Unlike model-parameter or inference-time scaling, it relies on selective retrieval to supply relevant information without filling long context windows. In MemAlign experiments on Databricks Genie Spaces, adding labeled examples raised test scores from near zero to 70%, about 5% above an expert-curated baseline, while average reasoning steps fell from about 20 to 5; filtered user logs produced similarly strong gains, exceeding 50% after 62 records. Production use requires storage and retrieval for episodic and semantic memories with organizational and user-level scoping, plus controls that preserve permissions and sensitivity labels.
National Australia Bank (NAB) is working with Databricks as one of five design partners for Lakewatch, an Open Security Lakehouse intended for modern security operations. NAB, part of Australia’s critical infrastructure, ingests more than 30TB of security data daily while confronting AI-enabled threats, expanding digital services, and growing third-party integrations. The partnership brings NAB’s threat-informed cyber-defense experience to a platform designed to unify signals across environments, apply advanced analytics and AI-driven workflows, generate higher-confidence insights, and automate response actions. Lakewatch is presented as an open, composable, AI-native foundation built natively on the Lakehouse for organizations facing constantly evolving threats, supporting enterprise-wide correlation, proactive threat hunting, detection, monitoring, and response at scale.
Equinix replaced its self-managed Kubernetes environment on Amazon EKS to address operational sprawl caused by independently managed clusters and inconsistent infrastructure practices. The new shared services architecture assigns platform ownership to a cloud operations team while application teams focus on business services. It uses separate Workloads, Platform, and Network accounts: workloads run across two Availability Zones with ALB, Gateway API, Cilium, and Hubble, while shared data services, GitHub Runners, and platform services reside in the Platform account. The Network account provides cross-account and multi-Region connectivity through AWS Transit Gateway, Route 53 Resolver, and Direct Connect. Equinix reports 40% lower operational overhead, 4x higher deployment frequency, and adoption of a unified architecture across multiple business organizations.
Multi-hospital networks face rising imaging volumes, siloed on-premises PACS, radiologist routing bottlenecks, and storage that must expand for 7 to 10 years of retention. The proposed pattern uses a hub-and-spoke hybrid architecture: local PACS instances preserve LAN-speed reading, while a centralized AWS archive provides cross-facility discovery, disaster recovery, and lifecycle-managed storage. Modalities send DICOM through C-STORE to local VNA servers, which normalize and compress objects; asynchronous replication sends images to Amazon S3, while Amazon Aurora PostgreSQL stores metadata and routing information. The AWS deployment spans two Availability Zones, places PACS services behind Network Load Balancers, and includes CloudFront and AWS WAF. Storage guidance distinguishes S3 Intelligent-Tiering, Glacier Instant Retrieval, and Glacier Deep Archive according to access frequency and retention needs.
The best engineering reads, once a week.
