Systems product design · 2026

Certificate Authority Pool Management Console

Making a stateful infrastructure workflow understandable at a glance—without exposing users to the complexity underneath.

Read the case study LinkedIn

Production pool Healthy

Authority 01Active · receiving traffic

Authority 02Draining · completing in-flight work

Authority 03Disabled · excluded from routing

Single issuance endpoint→State-aware routing

RoleProduct design + full-stack engineering

TimelineMay–August 2026

ToolsFigma · Java · AWS

FocusState clarity, rotation, recovery

Confidentiality note. This case study recreates the product thinking with abstracted visuals. It contains no internal source code, customer data, or proprietary architecture.

01 · The problem

One endpoint. Multiple authorities. No room for ambiguity.

Customers needed to rotate and manage multiple Certificate Authorities without changing their applications or interrupting certificate issuance.

The hard part was not only routing traffic. Operators also needed to understand which authorities were available, what would happen during a transition, and how to recover safely when a member was unhealthy.

Design question

How might we make a complex pool feel predictable enough that an operator can rotate infrastructure with confidence?

02 · Users and needs

Platform operators

Needed a safe way to manage membership, see health, and know which actions were valid for each state.

Application developers

Needed one stable endpoint so backend rotations would not force application configuration changes.

Service teams

Needed observable transitions, explicit failures, and testable behavior across the console and service.

03 · Product approach

Designing the workflow from the state model outward

I treated reliability as part of the user experience. The interface had to communicate system behavior before an operator committed to a change.

Map the real workflow

I translated backend pool behavior into a task model: create a pool, add authorities, choose eligible members, rotate safely, and understand failures.

Make state actionable

Active, draining, and disabled became visible product states. Each state explained what the system could do and which operator actions remained available.

Reduce integration work

A single issuance endpoint kept applications independent from individual Certificate Authorities. Console workflows called the same lifecycle APIs.

Validate edge cases

RDE, integration, and end-to-end tests exercised state transitions, unhealthy members, failover, and rotation without interrupting issuance.

04 · Key artifact

A console that answers three questions immediately

What is healthy? Where will the next request go? What can I do next without creating downtime?

Recreated interface concept

Certificate authority pools / production-primary

POOL STATUS

Production primary

Available

Endpointpool/production-primary

Eligible members1 of 3

Routing modeState aware

MemberStateNew trafficAction

A Authority 01ActiveEligible

B Authority 02DrainingStopped

C Authority 03DisabledExcluded

05 · Interaction model

The state tells the user what happens next

Pool membership was modeled as a small state system. The console used the same model to make routing behavior and available actions predictable.

StateSystem meaningOperator action

ActiveEligible for new certificate requestsDisable or begin draining

DrainingCompletes in-flight work but receives no new trafficMonitor, then disable

DisabledExcluded from routingRe-enable when ready

ApplicationOne stable integration

request→

Pool endpointEvaluates member state

route→

Active authorityIssues certificate

06 · Validation

Testing the experience at the same boundaries as the service

The console could only feel trustworthy if its labels and actions matched real system behavior. I validated the complete workflow instead of treating the interface and backend as separate pieces.

Lifecycle coverageCreate, update, describe, list, and delete pool workflows.

Transition coverageActive-to-draining and draining-to-disabled behavior.

Failure coverageUnhealthy members, invalid actions, and failover paths.

End-to-end coverageConsole action through API response and final pool state.

07 · Outcome

A clearer mental model for a reliability-critical workflow.

The final system combined one issuance endpoint, explicit member states, console lifecycle workflows, and tested recovery paths. Applications stayed insulated from backend rotation while operators gained a clearer view of what the pool would do next.

01One stable endpoint reduced application-level configuration changes.

02Visible member states connected operator actions to routing behavior.

03Failover and rotation paths were validated across the deployed workflow.

08 · Reflection

What I carried forward

State is product language

Backend states become useful only when users can connect them to consequences and next actions.

Reliability shapes trust

Loading, recovery, invalid actions, and failure paths deserve the same design attention as the happy path.

Implementation sharpens design

Connecting the console to real APIs exposed assumptions early and kept the interface grounded in actual system behavior.