Back to engineering work

Enterprise SaaS platform

Multi-user draft, publish and event-recording workflows

Implemented backend lifecycle behavior for shared drafts, publishing, cancellation, role-based visibility and service event recording.

JavaREST APIsPostgreSQLRBACIntegration testing

The system

An enterprise analytics product allowed stewards to configure applications containing categories, dashboards and related settings before publishing them to end users. Multiple services also recorded user and application events.

What had to be solved

The platform needed a consistent draft lifecycle across multiple stewards: changes had to remain shared in edit mode, published users had to see only the released version, cancellation had to restore the correct state, and role restrictions had to be enforced across API and UI flows.

Non-negotiable requirements

  • Administrators and stewards could edit; ordinary users could not access draft operations.
  • A published version had to remain stable while a newer draft was edited.
  • Concurrent steward changes needed to converge on one shared draft.
  • Recorder integration had to be validated across independently running services.

What I implemented

  • Implemented and tested save, publish and cancel API behavior across draft and published versions.
  • Added request-context and role resolution for steward, administrator and end-user flows.
  • Diagnosed view/edit response inconsistencies affecting categories, dashboards and application state.
  • Integrated service events with the recorder and verified end-to-end persistence.
  • Validated lifecycle scenarios using API calls, database state and user-facing behavior.

Key implementation choices

01

Separate draft and published views

The active edit state and the end-user release were treated as distinct versions with explicit visibility rules.

02

Resolve actor context centrally

Role and user identity were derived consistently so lifecycle checks were not duplicated across controllers.

03

Test complete journeys

Validation covered sequences such as create, edit, publish and view instead of isolated endpoint success responses.

Engineering outcome

  • Multiple stewards can contribute to the same draft before one publishes it.
  • End users remain isolated from unpublished changes.
  • Lifecycle actions and application events can be verified across services and persistence layers.
Next case studyPayment APIs and resilient partner integrations