Designing microexperiences on the edge

Capital One’s Edge Engineers extend functionality of existing APIs to create robust, reusable experiences across our mobile products. To continually deliver the quality features Capital One’s customers expect, our Edge Engineers must be autonomous and empowered to rapidly ship quality code that will inherently depend on various backend systems. Additionally, the code must be maintainable from development, deployment, and support perspectives.

Accounting for all these factors can be difficult. Microservices architectural patterns address autonomous development and shipment concerns in a vacuum, but can become unmanageable from a development and support perspective as your suite of features grows. Especially given how many artifacts may exist in your codebase and production environment. Likewise, the “do one thing and do it well” microservices maxim does not always apply to how we view customer features.

Capital One Edge engineering addresses these concerns by building what we call Microexperiences for our products. What is a Microexperience?

Let’s break that statement down into its components and subcomponents.

Practical application of micro-design principles

Thoughtful separation of functionality

Microexperiences allow engineers to avoid a monolithic application without getting so granular that code maintenance and operational support becomes untenable. Microexperiences stress the thoughtful separation of functionality.

For example, say a customer wants to chronologically view all transactions associated with their checking account. To provide this experience, the app will need to retrieve a number of different transaction types (upcoming transactions, posted transactions, transfers, etc.), aggregate them together, and then sort them by date.

Instead of breaking each of these tasks into their own services that independently do not provide a valuable experience to the customer, the logic is grouped together into a singular transactions microexperience that provides a comprehensive experience to the customer. This provides the inherent safety benefit of micro-design principles in that any updates to this code can only impact an isolated piece of functionality, while also mitigating the impact codebase and artifact sprawl if we were to have different services to retrieve each type of transaction.

Experience autonomy

This plays into the larger concept of experience autonomy. Engineers can build microexperiences autonomously, promote them to production, and scale them independently based on traffic. A microexperience for login (which is used every time a Capital One customer engages with our mobile app) can be scaled to have more instances than a microexperience for viewing auto-loan details (which is used a subset of times by a subset of Capital One users). Likewise, a change to the mortgage microexperience is wholly isolated from the login microexperience, isolating the potential risks of the change.

Dependency-driven

Microexperiences built at the Edge inherently depend on various downstream dependencies. To ensure the best customer experience even when a dependency has latency or downtime, it’s essential that microexperiences embrace their dependency-driven nature. This means implementing patterns to ensure high resiliency such as circuit-breaking and cross-region redundancy, as well as handling failures gracefully for our clients.

Customer-facing experience

Because microservices are built on the “do one thing and do it well” maxim, they are often built from the data forward. Microexperiences are built from the client experience backwards serving Experience APIs, ensuring clients have a consistent experience across digital mobile channels.

Let’s go back to the checking account transactions example. By bundling the fetching and sorting of multiple transaction types into one artifact, this code could be seen as violating “do one thing and do it well.” But each “one thing” does not create a customer-facing experience on its own. All of these “things” must integrate with one another to create a cohesive experience for customers while requiring minimal client-side logic, so there is value in bundling this logic together.

Conclusion

Capital One’s Edge Engineers leverage the resiliency, autonomy, and maintainability of microexperiences to rapidly build and ship quality, reusable code consumed by our millions of monthly mobile users. We find microexperiences strike the perfect balance between micro-design principals and dependency-driven development to build exciting customer-facing experiences in the mobile space.