In this article, we continue from Part 1, where we began presenting a range of AI architecture patterns that function as reusable blueprints for effectively designing AI solutions. This can support you on your journey in identifying the appropriate one (or ones) for the problem you are trying to solve.
 |
| Photo by Jan van der Wolf from Pexels |
Data centric patterns.
Feature store pattern.
This one has become a foundational element of mature ML platforms because it centralises the entire feature engineering lifecycle, ensuring that models train and serve on consistent, high‑quality data. Instead of letting teams repeatedly rebuild the same user metrics, behavioural aggregates, or time slot signals, a feature store provides a single source of truth where these features are computed once, documented, versioned, and reused across many models. This shared infrastructure:
- Eliminates training‑serving skew, which is one of the most common causes of silent model degradation.
- Enables organisations to scale recommendation systems with reliable, low‑latency feature access. Here are some of the tools that operationalise this pattern, offering offline stores for historical data, online stores for real-time inference and registries:
- Feast: A free, open‑source feature store focused on simplicity and flexibility. It provides a registry, offline store, and online store but leaves feature transformation to your existing data pipelines. Best for teams that want control and low cost.
- Tecton: A fully managed, enterprise‑grade feature store with strong real‑time and streaming support. It automates feature pipelines and reduces operational burden. This, though, introduces proprietary tooling and higher lock‑in.
- Hopsworks: A hybrid of the two (2) above, offering first class batch and streaming features.
 |
| Illustrates Feature Store pattern for a recommendation System. |
Data mesh pattern.
The Data Mesh Pattern re-frames how large organisations manage and scale data by shifting from centralised pipelines to domain driven ownership. Instead of one monolithic data team serving every need, each business domain (e.g. sales, marketing, operations) treats its data as a product, complete with clear owners, quality standards, and service interfaces.
This decentralisation reduces bottlenecks and breaks down silos, enabling AI teams to access cleaner, more contextual data.
The tradeoff is cultural: adopting a data mesh requires new governance habits, cross‑domain collaboration, and a mindset shift toward shared responsibility.
Event Driven Architecture (EDA).
The EDA brings real time intelligence to AI systems by letting models react the moment something meaningful happens. Instead of relying on scheduled batch jobs, every event (e.g. a click, a purchase) triggers downstream logic such as updating a recommendation, recalculating a score, or enriching a user profile. This makes it ideal for personalisation engines.
Deployment and scalability patterns.
Serverless AI pattern.
The Serverless AI Pattern uses short‑lived, auto‑scaling cloud functions to run AI workloads without any need to manage servers or long‑running infrastructure. Models execute inside ephemeral functions (aka cloud functions) that spin up only when triggered, making this pattern ideal for low‑traffic or sporadic tasks like lightweight image moderation or periodic text analysis.
Because you pay only for actual execution time, it’s highly cost‑efficient, but it comes with tradeoffs: cold starts can add latency, and strict time limits constrain heavier workloads.
Edge AI pattern.
In this particular case the models are placed directly on devices. You can think about IoT.
Even when the limitations around compute, this can be a good solution for low latency and offline capabilities.
A smartphone, a drone, or other type of devices, enabling real‑time decisions without depending on cloud round‑trips. Edge AI also enhances privacy and reduces unnecessary data transmission.
Model-as-a-Service (MaaS).
The MaaS Pattern streamlines AI adoption by exposing powerful models through API calls, allowing teams to integrate advanced capabilities without managing any underlying infrastructure. Platforms like Hugging Face, Modelscope, Northflank, OVHCloud, Mistral, Aleph Alpha make this possible by hosting large collections of open and proprietary models and providing one‑click or serverless deployment options.
This pattern is ideal for startups and product teams that need fast, pay‑per‑use access to solutions such as sentiment analysis, text generation, or other AI capabilities without the operational overhead of training or hosting models themselves.
A/B testing pattern for AI.
The A/B Testing Pattern for AI brings scientific rigour to model deployment by running multiple versions of a model in parallel and comparing their performance on real production traffic. This approach can be used to optimise recommendation systems, where even small improvements in click‑through rate or relevance can drive meaningful business impact.
In practice, A/B testing routes a controlled portion of users to each model variant and measures outcomes such as accuracy, latency, cost, and user behaviour.
Platforms like AWS SageMaker support this pattern through multi‑variant endpoints that let teams distribute traffic across model versions or directly invoke specific variants for precise comparisons.
A little sneak peek at the next chapter…
In part 3 we will bring a few more patterns related to Security and governance, as well as emerging ones, such as:
- Explainable AI (XAI).
- Agentic RAG.
- Swarm.
- Others.
AI architecture and patterns - part I
AI systems can be complex. Architecture patterns provide reusable blueprints...
Acknowledgement.
Part of the content of this article leverage the following technologies:
- Mistral AI.
- Microsoft Copilot.
- VSCode.
- Mermaid.
