Seconds to understand and act
Users needed clear templates, early validation, a fast preview, confident mapping, and an honest explanation of what would happen next.
Selected work
Case study 02 · Enterprise performance data
Engineering a custom metrics import that stayed reliable after upload.
I designed and delivered the Custom Metrics workflow across file preparation, validation, schema mapping, asynchronous execution, recovery, and KPI reporting.
- Role
- Senior Full Stack Engineer
- Ownership
- Workflow architecture through production support
- Processing contract
- CSV files up to 10 MB, processed in 100 record chunks
- System path
- React, TypeScript, REST APIs, SQS, InfluxDB, Vitest
01 · Two clocks, one experience
A four step interface had to remain coherent across validation, queue processing, storage, recovery, and reporting.
Processing continued beyond the browser request
Validation, queueing, chunked processing, storage, and result aggregation continued after the browser request had finished.
My ownership
I defined the workflow rules, state transitions, API expectations, polling and cleanup behaviour, recovery paths, and verification strategy. I aligned Product, Design, backend, data, and QA around one lifecycle contract so the interface never implied certainty the system did not yet have.
02 · The product journey
Each step removed a different source of uncertainty.
The interface became progressively more specific: establish the contract, inspect the data, preserve its meaning, then hand work to the asynchronous system.
- 01Upload
Define the contract before accepting data
The user downloads the correct template, reviews the field specification, acknowledges the requirements, selects the destination metric, and uploads a CSV up to 10 MB. Invalid structure or format stops the journey before preview.
- Template and specification
- Metric identity and CSV gate
- 02Preview
Show enough evidence without rendering the dataset
Row and column totals establish scale while the first three records let users verify headers, values, and structure without making the interface carry the full file.
- Row and column totals
- First three rows for confirmation
- 03Mapping
Preserve meaning across two schemas
Required system fields are paired with CSV columns using sample values from the file. Execution remains unavailable until every mandatory mapping is complete.
- Required field coverage
- Sample values beside each mapping
- 04Execute
Hand off the work without losing the user
The import enters the queue, reports its lifecycle, and resolves into processed, successful, and failed totals with duration, error recovery, another import action, and KPI dashboard navigation.
- Recoverable queued status
- Row level results and next actions
03 · Behind Execute
One click crossed six system boundaries.
The interface stayed anchored to one import identity while responsibility moved from synchronous validation to asynchronous processing and back to a user-facing result.
- 01BrowserFile rules and required mappings
- 02Import APIRequest validation and import identity
- 03SQSDurable queue handoff
- 04WorkerValidated chunks of 100 records
- 05InfluxDBAccepted metric data
- 06Reporting APIAccepted metrics returned to the KPI dashboard
One canonical lifecycle
- Queued
- Processing
- Completed
- Partially failed
- Failed
04 · Recovery by design
Failure boundaries determined whether the workflow remained credible.
I treated failure as part of the normal product lifecycle, not an exceptional screen added after the happy path.
- 01Before the queue
Stop preventable errors early
A structurally valid file could still target the wrong metric or omit a required business field.
- Direction
- I treated specification acknowledgement, metric selection, file validation, and required mapping as product gates rather than advisory messages.
- Outcome
- Only data with a complete, explicit contract could reach execution.
- 02During processing
Let users leave without losing the import
Refreshing or navigating away could interrupt polling even though accepted work continued in the backend.
- Direction
- I separated client request cleanup from backend execution, anchored status to the import identity, and restored active or completed work from the Custom Metrics list.
- Outcome
- Users could return to the latest status, results, and error report without restarting the workflow.
- 03After processing
Make partial failure a useful result
Some rows could succeed while others failed validation, making a binary success or failure message misleading.
- Direction
- I presented total, successful, and failed counts together with duration, a downloadable row level error report, and distinct next actions.
- Outcome
- Successful records remained usable while rejected rows became specific, correctable work.
Verification and release
Verify the states users could actually encounter.
- Contract gates
- Specification acknowledgement, metric selection, file limits, preview readiness, and mandatory mappings.
- Lifecycle states
- Queued, processing, completed, failed, and partially failed behaviour with polling and cleanup.
- Recovery and release
- Refresh, result restoration, error reports, release validation, and targeted production fixes.
05 · Product outcomes
The import remained traceable from file selection to KPI reporting.
- Recoverable progress
- status and results remained available after refresh or return
- Actionable errors
- rejected rows could be corrected from a detailed report
- Connected insights
- successful metrics flowed into the existing KPI experience
- Durable identity
- one import record connected queue progress, results, and return visits
The durable unit was the import, not the browser session.
That decision kept progress, recovery, and partial results coherent while work moved through the API, queue, worker, storage, and reporting system.