Big Ideas in App Architecture

In iGaming, there's no room for error: transactions are bank-level regulated, traffic spikes are massive and unpredictable, and a minute of downtime means a customer lost to a competitor for good. It's one of the most demanding environments in app architecture and this episode goes inside it.Host David Joy sits down with Justin Cosnett, Chief Product Officer at Continent 8 Technologies.Justin has spent 14 years at Continent 8. He came up through technical operations, joined as the company's first pre-sales solution architect, and grew with it as iGaming became its core vertical. You can say when it comes to the online gaming industry, he’s seen it all and he and David walk through his journey together. The two begin by unpacking what makes iGaming so unique, from bank-level regulation to the Wire Act rules that keep transactions within state lines, and what it took to stand up infrastructure as new US states opened at a pace of roughly one a month.Justin breaks down why operators who over-provisioned during the gold rush are now chasing efficiency, why legacy databases have become "crown jewels" that are hard to hand over, and how Continent 8 and Cockroach Labs come together to deliver sovereignty and scale for joint customers. We also get into what's next, including AI agents that scan odds across providers in an instant and the coming battles between agents on the security front. Then we close with a round of Let's Make a Few Bets.Learn more about Cockroach Labs: cockroachlabs.comLearn more about Continent 8: continent8.com

This episode marks a big moment for Cockroach Labs, a refreshed brand and the introduction of Cockroach Continuum!David Joy sits down with Tara Jana (TJ), who joined Cockroach Labs earlier this year and has been deep in the work behind everything you're about to hear. TJ has spent 21 years at the intersection of deep technology and storytelling, starting as an engineer, moving through solution architecture and field engineering at Microsoft, then taking products like Amazon CodeGuru and Kendra to market before landing at Cockroach Labs. The two begin by unpacking what's shifting across the database industry as AI agents multiply faster than any team can manage and why the companies with a data foundation built to absorb that growth will scale successfully. That shift sets the stage for Cockroach Continuum, The Agentic Database Cloud. TJ breaks down what Continuum delivers and walks us through the foundation underneath it: database virtualization, elastic infrastructure through Plenum, and agent-assisted operations through Aegis. We also get into the economics of it all, including consumption-based pricing that means paying for what you use, not what you provision for peak demand. Learn more about Cockroach Labs: cockroachlabs.comLearn more about TJ: [LinkedIn]

Perry Krug has been close to databases his entire career — from Couchbase in the NoSQL era to three years at Pinecone working on vector search. In this conversation with David Joy, the two database industry experts discuss the shifts they’ve witnessed, for better or worse, and why at the end of the day, we will always love the database. David and Perry dive into:The arc from rigid relational systems to NoSQL to today's return of polyglot persistenceVector search and where it shares distributed-systems fundamentals & AI-era production realities Learn more about Cockroach Labs: cockroachlabs.com Learn more about Perry Krug: https://www.linkedin.com/in/perrykrug/

Generating working software with AI has never been easier, but every shortcut a team takes today is a debt it pays back later. In this episode, David talks with Sam Hilsman, co-founder and CEO of CloudFruit, a studio that builds ERPs, analytics platforms, and custom products — including a custom ERP for a Chicago fabrication studio. Drawing on a path that runs from philosophy and healthcare administration into technical leadership, Sam makes the case that speed is the most underpriced risk in AI-assisted building.Sam unpacks his "Everything Trap" thesis: every decision incurs "change debt," so teams should build "icebergs, not ice sheets" — going narrow and deep, tightly scoping, testing relentlessly, and resisting feature bloat.He traces how his own AI use evolved from simple writing tasks to daily coding, and why he now works primarily in Claude Code alongside tools like Playwright for QA and Remotion for video.He shares hard-won lessons from an early venture  (HiiBo) around context management and pivoting, the unsolved problem of authentication for agents, and where real moats, governance, and ethical guardrails still need to come from as agents scale.

​Most teams moving AI into production quickly discover that generating an output is the easy part; running it reliably, efficiently, and at scale is a discipline of its own.In this episode, David talks with Philip Kiely, engineer at Baseten and author of Inference Engineering, a free guide to building and operating AI inference systems. Philip argues that every company will soon need a dedicated team to own inference, and draws on his work at Baseten to explain why it demands fluency across GPU optimization, distributed systems, model correctness, and developer experience all at once. He walks through how agentic workloads are reshaping inference demands, which open-weight models are worth watching, and key optimization techniques including KV cache reuse, quantization, and speculative decoding. Grab your copy of Inference Engineering here: https://www.baseten.co/inference-engineering/ 

In Kubernetes environments, concerns like retries, security, observability, and traffic control often end up scattered across application code, leading to duplicated logic, inconsistent behavior, and systems that are harder to operate and debug. The service mesh was designed to solve exactly that.In this episode, David talks with William Morgan, co-founder and CEO of Buoyant, about the origins of the service mesh and the role Linkerd plays today. Linkerd is an open source, CNCF-graduated service mesh for Kubernetes, built in Rust, that provides security, observability, and reliability. William traces the idea back to his time at Twitter, where the company’s move from a Ruby on Rails monolith to distributed services on Mesos exposed the hidden complexity of network calls and failure handling. He walks through what makes Linkerd unique: operational simplicity, built-in TLS and policy, retries, timeouts, rate limiting, and traffic splitting for safer rollouts. The two also explore open source sustainability, the difference between simple and easy, and how AI may create new platform challenges through new traffic patterns, nondeterministic code, and heightened security needs.

Most workflow and orchestration tools rely on external systems and fragile state management, making it hard for applications, especially AI agents to recover from failures or long running interruptions.In this episode, David talks with Peter Kraft, co-founder of DBOS, about a new approach to durable execution. DBOS is a lightweight, database-backed library that checkpoints program state so applications can resume after crashes, upgrades, or API failures. Originating from Stanford research with Matei Zaharia and Michael Stonebraker, the idea is to make software as durable as data by storing application state in the database. Peter walks through what makes DBOS unique: the ability to run in-process while still giving you the durability, distribution, and observability you'd expect from a dedicated orchestration layer. The two also explore how AI agents will create new reliability challenges and why CockroachDB is a natural fit. 

Most observability platforms are built around siloed signals, metrics, logs, and traces; not the rich context engineers actually need. The architecture of observability tooling hasn’t kept pace with the architecture of today’s distributed systems. In this episode, David sits down with Charity Majors, co-founder and CTO of Honeycomb.io and co-author of Observability Engineering, to rethink how modern teams understand production systems. Charity argues that the “three pillars” model is outdated, making the case for wide, structured events that preserve context and embrace high-cardinality data so engineers can ask better questions in real time.Drawing on lessons from operating Parse  and its challenging acquisition by Facebook, Charity explains how those experiences shaped Honeycomb’s fast, custom-built observability engine. The two also  explore how AI agents could soon close the loop between code changes and production validation, and Charity previews the upcoming second edition of Observability Engineering, including a new focus on observability governance for CTOs. Links for Charity:charitydotwtf.substack.com,honeycomb.io/blog, x.com/mipsytipsy

Most CI/CD pipelines are built to detect failure, not to resolve it. As software systems grow more distributed and complex, that limitation is becoming a bottleneck for resilience.In this episode, David sits down with Tomer Karin, a seasoned software architect in the automotive industry, to explore a new paradigm he calls Continuous Integration and Continuous Solution (CI/CS). Tomer argues that the future  of automated software development isn’t just faster feedback loops, it's systems that can autonomously remediate failures using AI.Tomer shares how his years of working on large-scale automotive software revealed the inefficiencies of traditional development pipelines, where engineers spend significant time diagnosing and fixing issues instead of building new capabilities. With CI/CS, AI agents don’t just identify failing builds, they apply fixes that are verified through existing test pipelines, allowing teams to start the next day with a healthier codebase.Join us as we discuss:Why traditional CI/CD breaks down as systems scale and complexity increases What Continuous Integration and Continuous Solution looks like in practiceHow AI agents can safely diagnose and fix software failuresWhere human oversight fits into autonomous development pipelinesThe economic and productivity impact of autonomous software workflows

Most databases are designed for success cases. Real systems fail– the difference is whether they’re built and tested for it. In this episode, David sits down with Spencer Kimball, co-founder and CEO of Cockroach Labs, to explore the architectural and testing decisions behind CockroachDB, and why validating systems under worst-case conditions is essential to building reliable infrastructure at scale. Spencer shares the origin story of CockroachDB, tracing it back to his time at Google, where working on large-scale data systems and helping build Google Spanner exposed the limitations of existing database technologies. Motivated by the limits of existing database designs, Spencer and his co-founders left Google to build a resilient, scalable, open-source database designed for a world where failure isn’t an edge case, it’s the norm.Plus, Spencer and David discuss how emerging AI workloads are reshaping expectations for database infrastructure by increasing scale, stressing latency budgets, and raising the cost of failure.Join us as we discuss:How Google Spanner inspired the creation of CockroachDBDesigning a database that assumed failure by default What resilience means at massive scaleHow AI is changing the demands placed on modern databasesHow the Cockroach Labs–IBM partnership reflects a broader shift in enterprise modernization Spencer’s futuristic vision for databases, from AI automation to outer space