← ALL WORKPROJECT 02 / 05

Product Information & API Platform

A backend platform built around structured product information, document management, APIs and reliable coordination between database and file-storage operations.

ROLE
Software Engineer
FOCUS
Backend / Data / Integrations
STACK
.NET / REST API / PostgreSQL / S3
TYPE
Professional work
Conceptual illustration of product information & api platform; not a client screenshot
Conceptual illustration of the engineering problem

THE CONTEXT

Business information lived across structured data, documents and connected systems. Applications needed useful business operations without having to understand every storage or integration detail underneath.

THE CHALLENGE

The hard part was not simply creating CRUD endpoints. A business operation could cross database state, object storage, version information and workflow state.

Partial success could leave those parts disagreeing. Retries and concurrent changes needed deliberate handling, rather than another attempt at the same happy path.

MY ROLE

I worked on backend services, APIs and workflow logic for product and document operations. This included PostgreSQL data modelling, persistence, business rules and integration workflows.

The work was about implementing useful business operations, not merely exposing database tables through endpoints.

HOW I APPROACHED IT

I treated multi-step operations as consistency problems: validate first, make state changes explicit, and consider what happens if a later step fails.

Transactional thinking, retry safety and version awareness shaped the workflows. Database changes and file operations needed clear responsibilities and predictable recovery when an operation could not complete.

CONCEPTUAL WORKFLOWA public explanation of the flow
  1. 01Client / application
  2. 02REST API
  3. 03Business logic
  4. 04Database + object storage
  5. 05Integrations

ENGINEERING DECISIONS

01

Business-oriented APIs

Expose operations that reflect the workflow instead of coupling callers to storage tables.

02

Relational modelling

Model the relationships between products, documents and lifecycle state in PostgreSQL.

03

Validate before persistence

Check an operation’s preconditions before changing persistent state.

04

Consistency boundaries

Use atomic business operations where appropriate and account for file-storage failures.

05

Version and retry awareness

Treat conflicts and repeated requests as expected workflow conditions.

06

Separate responsibilities

Keep business rules distinct from the mechanisms used to store files and exchange data.

OUTCOME

Backend behavior stays predictable under retries, concurrent changes and failures, with business workflows that do not depend solely on the happy path.

Selected identifying and implementation details are omitted because this work was completed for a client.