Irina Safonova · architecture case← Back to portfolio

Anonymized case study

Secure multi-tenant data and AI platform

Architecture for an early-stage B2B SaaS product that ingests operational data from several external sources, maps it into a normalized domain model, applies deterministic business rules, and uses AI as a controlled explanation and investigation layer.

Role: Contract Lead Solution ArchitectStage: Early product developmentDomain: B2B data operationsConfidential product

01 · Problem

Different sources, one reliable operational model

The product needed to collect data from multiple external systems whose schemas, identifiers and data quality differed. The resulting output had to remain reliable, reproducible and auditable across multiple client organizations.

Data challenge

Different source structures, missing values, inconsistent identifiers and changing source formats.

Business challenge

Core matching and calculation results could not depend on probabilistic model output.

Security challenge

Tenant context had to remain explicit across APIs, storage, jobs and AI-assisted workflows.

02 · Constraints

Architecture had to support an early product without pretending it was already hyperscale

Strict logical separation between client organizations.
Several source types, including APIs, structured files and external platforms.
Deterministic and reproducible business processing.
AI permitted for interpretation, explanation and assisted investigation, not as the source of truth.
Incremental delivery with limited early-stage engineering capacity.
Components needed clear boundaries so they could be separated later when volume justified it.

03 · Architecture

Layered processing with tenant context and explicit trust boundaries

Authentication establishes the user and tenant at the platform boundary. From that point onward, tenant identity is carried explicitly through every request, storage operation, background job and AI-assisted action.

User / client applicationSigns in and requests access to tenant-owned data and workflows.

→

Authentication & authorizationValidates identity, membership, role and permitted tenant scope.

TENANT CONTEXT · authenticated identity · organization ID · role / permissions · correlation ID

01Source connectorsAPIs, files and external systems enter through tenant-owned connector configurations.

02Ingestion & validationRecords are validated, typed, deduplicated and tagged with tenant context.

03Normalized modelSource structures map into shared entities without losing tenant ownership.

04Deterministic processingRules, matching, calculations and exception generation remain reproducible.

05Controlled AI layerOnly authorized, scoped evidence is supplied for explanations and investigation support.

06Product APIsTenant-aware endpoints return results, exceptions, evidence and audit metadata.

Data accessEvery query is tenant-scoped; UI filters are not the security boundary.

StorageRelational rows and source artifacts preserve tenant ownership and access policy.

Background jobsTenant identity is included in job payloads and revalidated during execution.

AI requestsContext is selected after authorization; model output cannot update trusted state directly.

Trust boundary: deterministic services own business truth. AI-generated explanations remain derived, reviewable output linked to the evidence used to produce them.

04 · Key decisions

Decisions that shaped the system

Deterministic processing and AI inference are separate.

Business-critical calculations remain testable and reproducible. AI helps explain results and navigate exceptions but does not silently alter the underlying truth.

The internal model is normalized rather than source-shaped.

New connectors map into a shared domain model, preventing source-specific assumptions from spreading through the application.

Tenant context is propagated, not inferred.

Requests, storage access and background jobs carry tenant identity explicitly. UI filtering alone is not treated as isolation.

Modularity before microservices.

The early deployment keeps operational complexity proportionate to product maturity while preserving boundaries that allow later extraction.

05 · Trade-offs

What was deliberately not over-engineered

Not every workflow needed an event bus on day one; scheduled or queued processing was sufficient where latency allowed it.
Service boundaries were defined in code and data ownership before being deployed as independently operated services.
The system prioritized auditable processing and clean data contracts over premature infrastructure scale.
AI functionality was constrained to cases where uncertainty was acceptable and visible to the user.

06 · Security and isolation

Tenant context, authentication and data isolation

Authentication

Identity is validated at the platform boundary before application or data access is granted.

Authorization

Organization membership and role determine which tenant, operations and evidence a user may access.

Data isolation

Tenant ownership is enforced in the data-access layer, storage paths and background workflows, not merely in the interface.

AI isolation

Only authorized structured context is assembled for model requests; generated output is never treated as trusted system state.

07 · Deployment approach

Practical deployment with room to evolve

The initial design uses a Python backend, tenant-aware data access, PostgreSQL-style relational storage, object storage for source artifacts, and background workers for ingestion and processing. Azure services can support managed AI integration and event-driven workloads where appropriate; the architecture does not require every component to become a separate cloud service immediately.

This is intentionally an architectural description rather than a claim that every possible cloud component was already deployed in production.

08 · My contribution

What I was responsible for

Defined the target architecture and system boundaries.
Designed the normalized domain model and ingestion flow.
Defined the separation between deterministic logic and AI inference.
Designed the tenant-isolation approach.
Mapped product requirements into technical concepts, implementation slices and backlog items.
Contributed hands-on to implementation where required.

09 · Current status

Incremental product development

The product is in early-stage development. Core architecture, data flows and implementation priorities have been defined, with functionality delivered incrementally. Product names, customer data, commercial rules and detailed infrastructure identifiers remain confidential.

Discuss a similar system