Architecture

Last week, *The Register* reached out to the major AI application vendors—Microsoft, SAP, Oracle, Salesforce, ServiceNow, and Workday—and asked a simple question: How much liability do you accept when your AI agents make bad decisions? Microsoft and SAP declined to comment. Oracle, Salesforce, ServiceNow, and Workday didn't respond. That silence is your answer. For every CISO, CRO or head of legal deploying AI today, that silence has a direct consequence: You are the insurer of last resort for your vendor's model.

Last year, researchers disclosed EchoLeak (CVE-2025-32711), a zero-click Indirect Prompt Injection in Microsoft 365 Copilot. A poisoned email forced the AI assistant to silently exfiltrate sensitive business data to an external URL. The user never saw it, never clicked a link, and never authorized the transfer, but the data left anyway. Most leaders I talk to think they are "covered" because their LLM provider is SOC2 compliant or has a signed DPA. However, in the eyes of the law, the liability remains with the deployer

Zero trust security is a security model that assumes all network traffic is untrusted, regardless of its source or destination. This approach requires strict verification of every request, regardless of whether it originates from inside or outside the network. In microservices architectures, where applications are composed of multiple independent services that communicate over the network, or across clouds, zero trust security is essential to protect sensitive data and prevent security breaches. In this article, we will explore how zero trust security can be implemented in microservices architectures to enhance security and protect sensitive data.

Attempting to fit every component of a monolithic architecture into a microservice is like trying to fit a square peg into a round hole. Not everything belongs, and forcing it only distorts the integrity of both the structure and the function. In this blog we will provide a framework to identify which functionalities or modules are ripe for migration to a microservice and which are not.

Message brokers play a crucial role in addressing the challenges of distributed architectures and microservices by providing a reliable, flexible, and scalable means of communication between services. In this blog we will explore the role of message brokers, take a deep dive into some mechanisms used by message brokers to address common challenges in distributed systems.

While the database-per-service paradigm in microservices fosters many advantages like isolation, agility, scalability and resilience, it also poses a significant challenge in managing transactions that span across multiple services. In this article, we discuss this and common patterns to address this challenge.

Scalability, agility & delivery speed, resilience and organization alignment are some of many reasons for the shift to microservices in the past decade. Microservices break down the application into smaller, independently deployable services, with each service responsible for a specific functionality.