Customer Journey: The First Principles Approach to SDLC

How Robinhood is rethinking reliability by modeling systems around customer outcomes, not just service health.

Every time a customer submits a stock order, they initiate a complex web of service dependencies. From the user’s seat, it’s a simple, linear path. From the system’s seat, it’s a chaotic explosion of data and services. If your reliability model treats every service failure as a 'degraded' event, you’re missing the point—and potentially ignoring the only failures that actually stop a customer from finishing their order.

A sequence of mobile UI screens showing an illustrative user flow for submitting a stock order.

In this reality, not all service dependencies carry equal weight. Some must succeed for the transaction to complete, while others can fail without blocking the user intent. For example, a fee preview can time out or news feeds may fail to load. This degrades the UI but doesn't stop the order. Conversely, a buying-power check failure stops the process entirely. Most systems currently treat all these failures as equal 'service degradation,' failing to distinguish between the nuisance failures and the critical ones.

This service-centric model fits how teams are organized, but it fails to accentuate what actually matters.

In the example above, the non-blocking failures appear as "degraded" on the service dashboards; and the alerts are technically accurate. These dashboards, with their standard RED (Rate, Errors, Duration) metrics, are built to answer "Is this service healthy?" but they cannot answer, "Is the customer's objective still achievable?"

Without that distinction, prioritization at scale breaks down: We end up debating severity instead of deriving it, teams optimize for local metrics, and investment follows the loudest voice rather than true customer impact.

We solved this by modeling the system exactly how the customer experiences it: A journey with distinct blocking and non-blocking dependencies.

Solid lines are blocking; failure fails the outcome. Dashed lines are non-blocking; failure degrades the journey. All edges and nodes are illustrative only and do not represent actual production system

Against this model, our customer impact puzzle resolves instantly. It also makes architectural decisions explicit. For example, we classify the Compliance Check as blocking with the rationale "fail-closed; if the check fails, trading is not permitted." This critical decision no longer lives in one engineer's head; we have turned it into a visible, codified property of the system.

By encoding these dependencies, our journey model gives every failure a clear and immediate blast radius.

We initially seeded our journey catalog by combining automated analysis with human validation. We used Large Language Models (LLMs) to scan key sources—such as source code, public-facing help content, and risk repositories—to generate a first-pass set of customer journeys. We then refined this initial list through collaborative workshops with product and business leaders to validate criticality, completeness, and correctness.

Once established, we structure each journey model around three complementary perspectives: intent, possibility, and reality.

Intent (what started):

At the client edge, our application layer assigns a journey identifier to every request. We propagate this identifier through all downstream calls, allowing us to trace every span and service interaction back to a specific customer action.

Possibility (what could happen):

We use static analysis of server code to build the full call graph. This captures all potential dependencies across services, including execution paths that we may not routinely exercise in production.

Reality (what did happen):

We analyze production traces to see which paths actually execute, which dependencies the system reaches, and how it behaves under real market conditions.

Each analysis step fills the blind spots of the others: Static analysis over-approximates, traces under-sample, and together they converge on an accurate model. To keep pace with rapid system changes, we continuously reconcile each journey model against its previous version to surface new dependencies, track changes to the critical path, and retire obsolete routes.

Building this framework wasn't without its hurdles. Merging static analysis with dynamic production traces presents a significant data reconciliation challenge. Static analysis frequently over-approximated possible code paths (generating "graph noise" from dead or rare code blocks), while production traces under-sampled paths that only trigger during black-swan market events. We needed to build custom filtering logic to merge these views without polluting the catalog.

Additionally, using LLMs for the initial seeding required rigorous prompt engineering and human-in-the-loop validation to catch hallucinations. Finally, we had to carefully optimize our tracing propagation to ensure that injecting journey identifiers across billions of daily calls didn't introduce noticeable latency overhead to our core trading paths.

We recognize that not all journeys carry the same weight for the business. Submitting an order or transferring funds must succeed with near certainty, while viewing charts, recommendations, or news can tolerate minor degradation. We assign each journey a level of criticality based on its Maximum Allowable Downtime (MAD), reflecting how long it can be unavailable before causing unacceptable customer or business impact.

Criticality is a property of the journey itself. We cascade this criticality down to the blocking dependencies in the journey graph, making it explicitly clear which parts of the system must meet our highest reliability bar. This allows us to deliberately shape our system architecture, making paths that must succeed highly resilient while safely isolating those that can degrade gracefully.

We group our customer journeys into a single, navigable wheel spanning the entire Robinhood product surface. Each leaf represents a specific customer journey: Place an Order, Transfer Funds, Withdraw Crypto. In one centralized view, the system answers a question that isolated service dashboards cannot: Which customer journeys are currently at risk?

Reliability is overlaid on this view using outcome-based SLOs. Level 3 shows the success rate for each customer journey, Level 2 reflects traffic-weighted aggregation at the product level, and Level 1 represents rolled-up domain health. Values indicate the percentage of successful user outcomes relative to defined SLO targets. All numbers shown are illustrative only and do not represent actual production metrics.

Our journey catalog covers every customer journey, reflects the system as it actually runs, and evolves automatically as the system changes:

• Comprehensive - The model represents the full Robinhood surface area. Our static analyzers and dynamic tracers continuously surface every customer journey the system supports. We assign each journey a business-aligned level of criticality based on its MAD with full agreement from product and business leaders.

• Accurate - The journey graph (services, edges, and execution paths) reflects real system behavior. We build it from a combination of static analysis and production traces, ensuring every critical path is fully visible.

• Sustainable - As code changes and new paths emerge, the model updates itself. We surface drift immediately rather than discovering it during an active incident. Our Critical User Journeys (CUJs) evolve with the business in a hands-off, automated way.

The journey model serves as our single source of truth across engineering. Instead of each discipline operating on its own proxies, we all operate on the exact same customer journey artifact, aligning how we build, validate, and operate systems around customer outcomes.

During Development (Engineering, Quality): 

The journey model exposes our system architecture through the lens of customer outcomes, making critical paths explicit and guiding where we must build resilience. Because we define criticality at the journey level, we directly derive our service tiering from the journeys a service supports; any service that can block a mission-critical journey automatically becomes Tier 0. We extend this same principle to testing: our test coverage scales with journey criticality and we measure it in terms of outcomes, ensuring our validation efforts focus heavily on what must succeed.

Run-time (Reliability, Resilience):

We carry this exact same model directly into production. Our outcome-based SLOs complement traditional service-level SLOs, measuring reliability in terms of completed customer actions. We continuously evaluate dependencies against journey requirements, meaning any dependent service that falls out of compliance is instantly surfaced within the context of customer impact. This allows us to determine incident severity via affected journeys rather than subjective human judgment.

Furthermore, we make our fault injection outcome-driven: we use non-blocking failures to validate graceful degradation and blocking failures to verify fail-safe behavior. We also use journey criticality to dynamically adjust sampling rates for observability primitives like distributed tracing, reducing our mean time to detect and resolve issues (MTTD/MTTR) for the customer journeys that matter most to the business. 

Oversight (Governance, Risk, Compliance):

The journey graph turns compliance oversight from a periodic document review into a continuously verified property of our running system.

• For Business Continuity Planning: We can instantly check a continuity plan against the live journey graph to flag any critical path that is missing a documented recovery procedure.

• For Vendor and Concentration Risk: A third-party vendor on a blocking path inherits the exact same reliability requirements as an internal service. We evaluate a vendor outage against the customer journey it would break, not just the text in its contract.

• For Risk Management: We can configure our CI/CD gates to block any code change that would introduce a new single point of failure on a mission-critical journey, preventing systemic risk before it ever hits production.

The running system itself becomes our source of truth for compliance, replacing static documentation.

Grounding reliability in the customer journey makes our engineering decisions significantly more actionable. Service dashboards remain deeply important, but they only tell part of the story. By modeling what our customers are trying to accomplish, identifying which dependencies are truly blocking, and monitoring how those paths behave in production, we can make faster, better decisions across architecture, testing, incident response, and risk management. This first-principles, journey-based approach helps us shift reliability from a service-centric measure of infrastructure health to an outcome-based guarantee that our customers can successfully do what they came to Robinhood to do.

• We should measure reliability by whether a customer can complete their intended action, not just by whether individual services are healthy.

• Customer journey modeling helps us accurately distinguish between catastrophic blocking failures and non-blocking UI degradation.

• By combining static analysis, production traces, and human validation, we can build dynamic journey models that reflect both potential and real-world system behavior.

• We leverage journey criticality to help engineering teams derive service tiers, testing depth, observability priorities, and incident severity directly from customer impact.

• A shared journey model gives our engineering, reliability, resilience, governance, risk, and compliance teams a unified source of truth, helping us proactively detect architectural drift, eliminate subjective prioritization, and build systemic resilience around the paths that matter most.

Mustapha Ismail is on the Reliability and Standards team at Robinhood, where he focuses on engineering systems and reliability practices, connecting technical architecture decisions to customer outcomes.

Sven Goedicke is on the Enterprise Resilience team, where he works to build a culture of preparedness and adaptability through coordinated planning and regular resilience testing to protect Robinhood during disruptive events.

Abhishek Maloo leads the Engineering Excellence Organization at Robinhood, defining and enforcing software development standards to drive confidence, efficiency, quality, and rigor.

Interested in learning more about building at Robinhood? Check out the careers page.