Aerospike Cloud Console

Aerospike Cloud is an enterprise platform for deploying and running high-performance distributed databases in the cloud. I joined the Cloud team as a senior front-end engineer alongside other frontend engineers. The most critical piece of the product was the provisioning wizard: the multi-step flow where a prospect configures and creates their first database. That's the moment a trial becomes revenue. When I arrived, it was fragmented, stateless on refresh, and running alongside a separate legacy admin console (ACMS) that hadn't been unified into the main platform. I planned the wizard's overall architecture and built many of its pages; other frontend engineers on the team shipped additional wizard and console work following those patterns. I also drove testing strategy, legacy integration, and mentorship during a live customer migration where mistakes were costly.

Title

Senior Front-End Engineer, Cloud Team

Context

Senior FE on a cross-functional Cloud team with other frontend engineers, backend engineers, and product. I architected the provisioning wizard; the team built against those patterns.

Scope

Wizard architecture and many core pages; component patterns, state management, testing, legacy integration, Access Manager, and mentorship across the console.

Enterprise customers dropping off mid-setup meant lost revenue. The provisioning flow had no clear progress tracking, state wasn't persisted across steps (a refresh meant starting over), and the business logic — availability zones, replication factors, cluster sizing — was deeply interdependent in ways no existing library handled cleanly. On top of that, a separate legacy console (ACMS) existed alongside the main platform, creating a disjointed experience during a live customer migration window where mistakes were costly.

• StepIndicator

  Problem

  Users dropped off a confusing multi-step setup with no sense of place.

  Fix

  A flow-aware tracker where business logic, not position, controlled which steps were navigable.

  Result

  Completed, active, error, and upcoming states were explicit; only valid steps were jumpable.

• Smart defaults and presets

  Problem

  Less technical users misconfigured clusters when every option was raw.

  Fix

  Surfaced sensible defaults from use case, company type, or earlier selections.

  Result

  Users could progress with a valid starting config instead of guessing.

• Inline validation and error messaging

  Problem

  Bad configurations only surfaced at submission, after the work was already done.

  Fix

  Step-level validation blocked progress until the current step was valid.

  Result

  Errors were caught in place, not after a failed launch attempt.

• Review-before-launch summary

  Problem

  Launching a cluster from a half-seen config made costly mistakes easy.

  Fix

  A summary screen showed the full configuration and kept it editable.

  Result

  Users confirmed or corrected everything before cluster creation ran.

• Conditional and branching steps

  Problem

  A one-size-fits-all form showed irrelevant options for every cluster path.

  Fix

  The flow adapted based on prior answers, hiding unused steps and fields.

  Result

  Each path only asked what that cluster actually needed.

• Conditional state reset

  Problem

  Changing an upstream value left stale downstream data that silently broke sizing.

  Fix

  Changing availability zone count invalidated and recalculated node sizing constraints.

  Result

  Downstream fields stayed consistent with the current upstream choices.

• Async-dependent field handling

  Problem

  Regions and instance types loaded from APIs and blocked the flow mid-step.

  Fix

  Fields loaded asynchronously without freezing or blocking progress.

  Result

  Users could keep working while dependent options arrived.

• Back navigation with data preservation

  Problem

  Going back a step felt like starting over.

  Fix

  All entered data persisted when navigating to a previous step.

  Result

  Users could revise earlier answers without re-entering the rest.

• DatabaseSelectionTable

  Problem

  A refresh wiped in-progress work and forced users to start over.

  Fix

  React Context state hydrated from localStorage across steps.

  Result

  Users never lost their configuration on reload or a return visit.

• Contextual inline docs panel

  Problem

  Users left the flow to look up Aerospike docs, and often didn't come back.

  Fix

  Fetched docs into a collapsible sidebar styled to the console, scoped to the current page.

  Result

  Help stayed in-context instead of sending people out of the wizard.

• Dual-mode JSON/YAML config editor

  Problem

  Advanced Aerospike options weren't exposed in the UI, so power users were stuck.

  Fix

  A JSON/YAML editor with conflict detection against values already set in the wizard.

  Result

  Developers could configure any option, with clashes surfaced before launch.

• Access Manager

  Problem

  Org admin — members, API keys, secrets, audit logs — needed a home in the console.

  Fix

  Tabbed list-and-dialog CRUD per entity: fetch rows, add/edit via dialogs, REST calls.

  Result

  Admins could manage org settings without leaving the Cloud Console.

• ACMS legacy console integration

  Problem

  ACMS (Aerospike Cloud Managed Service) ran on a human ops model while Cloud DBaaS needed self-serve provisioning — both during a live migration.

  Fix

  Unified the legacy request-style console with the new self-serve wizard, replacing rigid RJSF schema forms on the provisioning path.

  Result

  Customers could migrate without disrupting the in-flight cutover.

• Async launch error handling

  Problem

  Cluster creation after Review could fail asynchronously with no clear recovery path.

  Fix

  Surfaced errors on the launch step; users could fix config and retry from the same draft.

  Result

  A failed launch did not force starting the wizard over or risk double-creating.

• Vitest and Playwright coverage

  Problem

  A revenue-critical wizard had no automated coverage for component logic or the full flow.

  Fix

  Playwright on critical paths and major happy paths; Vitest on smaller funnels and unit-level logic.

  Result

  Must-not-break provisioning paths had E2E coverage; supporting logic had unit tests.

• Mentorship

  Problem

  Junior engineers on the Cloud team needed consistent patterns to ship wizard and console work safely.

  Fix

  Mentored two junior front-end engineers on the wizard architecture, component patterns, and testing.

  Result

  They shipped later Cloud UI work reusing the wizard and step patterns established here.

The unified flow drove successful enterprise migrations away from the legacy ACMS console. Customers reported that persistence meant they no longer lost the wizard on refresh or leaving the page — they could finish later without starting over. The component patterns I introduced became the architectural foundation for subsequent Cloud UI work — they outlasted my tenure.