---
title: "2026-08-28 VxData multipart API architecture review"
description: "Reviewed PR #356 storage routes, service, and shared schemas for consolidation and interface ownership."
image: "https://docs.virdx.dev/img/virdx-social-card.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.virdx.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# 2026-08-28 VxData multipart API architecture review

## Work Done

Reviewed PR #356 at `d2ab806c..HEAD`, focused on the VxData storage route, service, and shared schema files. No monorepo files were edited. Reported ranked opportunities around lifecycle target ownership, concurrent multipart overwrite risk, constrained and non-positional part protocols, moving all HTTP models into `vxdata-schemas`, injecting a storage service into routes, isolating protected MinIO calls behind an owned adapter, and consolidating upload allocation and S3 path parsing.

## Lessons Learned: Pitfalls

The infrastructure SOP index was useful for routing but did not contain PR-specific multipart design context. The repository's upload specification and SDK direct implementation were the useful supporting sources. The knowledge checkout initially failed `git pull --ff-only` with "Cannot fast-forward to multiple branches" even though the checkout later showed a clean `main...origin/main`; agents should inspect status before assuming the knowledge repo is stale.

## Lessons Learned: Improvements

The durable vxData SDK/schema SOP could state one architectural rule explicitly: all public storage wire models belong to `vxdata-schemas`, while vendor-specific S3 operations should sit behind an owned adapter. It could also document that object nonexistence checks before multipart initiation are not sufficient to prevent two concurrent upload sessions from completing to the same key.

Source: https://docs.virdx.dev/knowledge/inbox/2026-08-28-infrastructure-vxdata-multipart-api-architecture-review/index.mdx