<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Integration on</title><link>https://www.ardanlabs.com/tags/integration/</link><description>Recent content in Integration on</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 24 Jul 2025 00:00:00 +0000</lastBuildDate><atom:link href="https://www.ardanlabs.com/tags/integration/index.xml" rel="self" type="application/rss+xml"/><item><title>Fixing Fintech Transaction Delays Without Direct Database Access</title><link>https://www.ardanlabs.com/case-studies/embedded-engineers-reduced-fintech-transaction-delays-without-direct-db-insights/</link><pubDate>Thu, 24 Jul 2025 00:00:00 +0000</pubDate><guid>https://www.ardanlabs.com/case-studies/embedded-engineers-reduced-fintech-transaction-delays-without-direct-db-insights/</guid><description>&lt;h2 id="overview"&gt;Overview&lt;/h2&gt;&#10;&lt;h3 id="the-challenge-transaction-latency-was-compromising-scale"&gt;The Challenge: Transaction Latency Was Compromising Scale&lt;/h3&gt;&#10;&lt;p&gt;As the fintech company’s platform grew, so did the demand for its database. Unfortunately, insert operations for critical payments began to slow down, affecting not just the financial layer but every system upstream.&#10;The real kicker? Their engineering team couldn’t access detailed database metrics due to permission constraints on RDS Performance Insights. With no clear line of sight into database internals, they were flying blind.&#10;That’s where we came in, not as external consultants, but as embedded team members ready to work shoulder-to-shoulder with their developers.&lt;/p&gt;</description></item><item><title>Scaling an AI Platform Securely Across Cloud and Air-Gapped Environments</title><link>https://www.ardanlabs.com/case-studies/scaling-an-ai-platform-securely-across-cloud-and-air-gapped-environments/</link><pubDate>Thu, 24 Jul 2025 00:00:00 +0000</pubDate><guid>https://www.ardanlabs.com/case-studies/scaling-an-ai-platform-securely-across-cloud-and-air-gapped-environments/</guid><description>&lt;h2 id="overview"&gt;Overview&lt;/h2&gt;&#10;&lt;h3 id="the-challenge-scaling-a-platform-without-slowing-down"&gt;The Challenge: Scaling a Platform Without Slowing Down&lt;/h3&gt;&#10;&lt;p&gt;The client, a growing AI startup, was developing a powerful microservices-based platform designed to deliver real-time language model capabilities to highly regulated industries.&lt;br&gt;&#10;From early on, they faced intense infrastructure constraints: every customer environment had to be HIPAA and SOC 2 compliant. The product needed to be deployable in cloud environments like AWS and GCP, but also in private, airgapped Kubernetes clusters where security rules were strict and connectivity was non-existent.&lt;br&gt;&#10;The internal team was capable but stretched. They were focused on building the product and lacked the specialized infrastructure experience needed to scale the system securely and reliably across environments.&lt;br&gt;&#10;The risk was clear: without the right expertise, deployment complexity would slow their roadmap, introduce security risks, and limit how quickly they could expand.&lt;/p&gt;</description></item><item><title>Building a Cross-Cloud Data Platform That Scales Without Lock-In</title><link>https://www.ardanlabs.com/case-studies/embedded-engineers-built-a-cross-cloud-data-platform-in-go-and-grpc/</link><pubDate>Mon, 21 Jul 2025 00:00:00 +0000</pubDate><guid>https://www.ardanlabs.com/case-studies/embedded-engineers-built-a-cross-cloud-data-platform-in-go-and-grpc/</guid><description>&lt;h2 id="overview"&gt;Overview&lt;/h2&gt;&#10;&lt;h3 id="the-challenge-distributed-data-at-enterprise-scale"&gt;The Challenge: Distributed Data at Enterprise Scale&lt;/h3&gt;&#10;&lt;p&gt;The client’s business relied on fast, reliable access to structured and unstructured data across services, teams, and environments. But building a system that could handle ingestion, validation, and delivery in a federated cloud landscape was no small task.&lt;br&gt;&#10;Each environment (EKS, GKE, and private K8s) introduced its own networking, storage, and identity constraints. Data had to move quickly and securely, but also remain observable, contract-driven, and testable. The internal engineering team needed support from experts who had done this before at scale.&lt;/p&gt;</description></item><item><title>Enabling Real-Time CRM Sync for Financial Advisors Without Breaking Existing Systems</title><link>https://www.ardanlabs.com/case-studies/embedded-engineers-delivered-crm-Synchronization-for-financial-advisors/</link><pubDate>Mon, 21 Jul 2025 00:00:00 +0000</pubDate><guid>https://www.ardanlabs.com/case-studies/embedded-engineers-delivered-crm-Synchronization-for-financial-advisors/</guid><description>&lt;h2 id="overview"&gt;Overview&lt;/h2&gt;&#10;&lt;h3 id="the-challenge-disconnected-crms-creating-chaos"&gt;The Challenge: Disconnected CRMs Creating Chaos&lt;/h3&gt;&#10;&lt;p&gt;Each advisor used a different CRM or split leads across several. As a result, no single source of truth existed, and the lead data diverged quickly. Syncing systems manually or building per-CRM scripts proved brittle and time-consuming. Data quality suffered, workflows were delayed, and firms struggled to generate accurate reports or provide consistent client service.&lt;/p&gt;&#10;&lt;h3 id="the-goal-deliver-real-time-synchronization-without-disruption"&gt;The Goal: Deliver Real-Time Synchronization Without Disruption&lt;/h3&gt;&#10;&lt;p&gt;The company needed a robust and extensible system that replicated lead and client records between CRMs. It had to be real-time, handle multiple data sources, and conform to the business rules of onboarding, contact assignment, and field mapping. Importantly, it had to work within the current toolset, allowing advisors to keep using their CRM of choice without a forced migration.&lt;/p&gt;</description></item><item><title>Scaling AI Systems with a Hybrid Rust and .NET Architecture</title><link>https://www.ardanlabs.com/case-studies/scaling-ai-systems-with-a-hybrid-rust-and-dotnet-architecture/</link><pubDate>Mon, 21 Jul 2025 00:00:00 +0000</pubDate><guid>https://www.ardanlabs.com/case-studies/scaling-ai-systems-with-a-hybrid-rust-and-dotnet-architecture/</guid><description>&lt;h2 id="overview"&gt;Overview&lt;/h2&gt;&#10;&lt;h3 id="the-challenge-bringing-rust-performance-to-a-c-ecosystem"&gt;The Challenge: Bringing Rust Performance to a C# Ecosystem&lt;/h3&gt;&#10;&lt;p&gt;LanceDb is engineered for speed, concurrency, and efficient semantic search—thanks to its Rust foundation and async-first architecture. However, its lack of a network service mode and primary focus on Python made it difficult to adopt for teams outside the Python ecosystem.&lt;/p&gt;&#10;&lt;p&gt;Our client’s AI infrastructure was built in C#. Replacing their stack wasn&amp;rsquo;t an option. They needed a way to access LanceDb’s performance while keeping their .NET development model intact.&lt;/p&gt;</description></item><item><title>Shipping a Mission-Critical Integration Without Slowing Product Velocity</title><link>https://www.ardanlabs.com/case-studies/embedded-engineers-delivered-a-mission-critical-integration-without-slowing-the-roadmap/</link><pubDate>Mon, 21 Jul 2025 00:00:00 +0000</pubDate><guid>https://www.ardanlabs.com/case-studies/embedded-engineers-delivered-a-mission-critical-integration-without-slowing-the-roadmap/</guid><description>&lt;h2 id="overview"&gt;Overview&lt;/h2&gt;&#10;&lt;h3 id="the-challenge-too-much-to-build-not-enough-time"&gt;The Challenge: Too Much to Build, Not Enough Time&lt;/h3&gt;&#10;&lt;p&gt;The company’s product roadmap was full. But the opportunity to integrate a powerful third-party API couldn’t be missed. Internally, there were no spare engineers with the time or the experience—to take it on. The internal team was delivering core roadmap items. Leadership wanted to accelerate time-to-market without disrupting momentum or reassigning internal developers.&lt;br&gt;&#10;The API itself was non-trivial: complex schemas, evolving versions, and strict rate limits. A half-baked integration could do more harm than good. This needed to be done right and fast.&lt;/p&gt;</description></item><item><title>Integration Testing in Go: Part II - Set-up and Writing Tests</title><link>https://www.ardanlabs.com/blog/2019/10/integration-testing-in-go-set-up-and-writing-tests.html</link><pubDate>Thu, 03 Oct 2019 00:00:00 +0000</pubDate><guid>https://www.ardanlabs.com/blog/2019/10/integration-testing-in-go-set-up-and-writing-tests.html</guid><description>&lt;h3 id="prelude"&gt;Prelude&lt;/h3&gt;&#10;&lt;p&gt;This post is the 2nd installment of a 2 part series about integration testing. You can read the first &lt;a href="https://www.ardanlabs.com/blog/2019/03/integration-testing-in-go-executing-tests-with-docker.html"&gt;installment&lt;/a&gt;, which is about executing tests in a restricted environment using Docker. The example repository that this post draws it examples from can be found in the &lt;a href="https://github.com/george-e-shaw-iv/integration-tests-example"&gt;integration-tests-example repo&lt;/a&gt;.&lt;/p&gt;&#10;&lt;h3 id="introduction"&gt;Introduction&lt;/h3&gt;&#10;&lt;blockquote&gt;&#10;&lt;p&gt;&lt;em&gt;”More than the act of testing, the act of designing tests is one of the best bug preventers known.” - &lt;em&gt;Boris Beizer&lt;/em&gt;&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Integration Testing in Go: Part I - Executing Tests with Docker</title><link>https://www.ardanlabs.com/blog/2019/03/integration-testing-in-go-executing-tests-with-docker.html</link><pubDate>Mon, 18 Mar 2019 00:00:00 +0000</pubDate><guid>https://www.ardanlabs.com/blog/2019/03/integration-testing-in-go-executing-tests-with-docker.html</guid><description>&lt;h3 id="introduction"&gt;Introduction&lt;/h3&gt;&#10;&lt;blockquote&gt;&#10;&lt;p&gt;&lt;em&gt;“Testing leads to failure, and failure leads to understanding.” - &lt;em&gt;Burt Rutan&lt;/em&gt;&lt;/em&gt;&lt;/p&gt;&#10;&lt;/blockquote&gt;&#10;&lt;p&gt;Burt Rutan is an aerospace engineer who designed Voyager, the first plane to fly around the world without stopping or refueling. Although Rutan was not a software engineer, his words speak volumes to the importance of testing, even testing software. Testing software in all forms is extremely important, whether it be unit, integration, system, or acceptance testing. However, depending on the project, one form of testing can be more valuable than the others. In other words, sometimes one form of testing can lead to better understanding about the health and integrity of the software than the other forms.&lt;/p&gt;</description></item></channel></rss>