Back to blog
Architecture·May 9, 2022

On the Inside: Delivering Frontend Solutions for AWS OpenSearch at Amazon

Working inside Amazon on AWS OpenSearch meant operating at a scale where every UI decision had real downstream consequences. Here's what that environment taught me about building interfaces that hold up.

A Different Kind of Scale

Most frontend work operates in a context where your users are a known group — a customer base, an internal team, a defined audience. Working on AWS OpenSearch at Amazon meant building interfaces used by engineers and data teams across thousands of organizations worldwide. The surface area was different. The pressure to get things right was different.

That context changes how you think.

The Technical Work

My role focused on delivering frontend solutions that integrated GraphQL middleware to streamline data flow between the UI and the underlying OpenSearch service. GraphQL was well-suited here — the ability to query exactly the fields needed, no more and no less, kept the interface fast and the payloads lean even as the underlying data models grew complex.

The state layer used Redux, which provided the predictability and debuggability that a system at this scale required. When something goes wrong in production for an AWS service, you need to be able to trace exactly what happened. A well-structured Redux store makes that possible. An ad hoc state solution makes it a nightmare.

Collaborating Across Disciplines

One of the most valuable aspects of this engagement was working closely with product and UX teams whose standards were extremely high. Design reviews were substantive. Architecture discussions involved senior engineers with strong opinions and the experience to back them up.

That environment raised my baseline. When the people around you hold their work to a high standard as a default — not as a special effort — it recalibrates what you expect from yourself.

Code quality was non-negotiable. Pull requests went through thorough architecture reviews. Nothing shipped that hadn't been examined carefully. It was slower in some ways, but the outcome was a codebase that held together under real-world load.

What It Reinforced

Building at Amazon's scale reinforced something I'd suspected but hadn't fully internalized: the decisions that feel small in development are often the ones that matter most in production. A component that renders a list efficiently at a hundred items might choke at a hundred thousand. A GraphQL query that returns a few extra fields feels harmless until you're handling millions of requests.

Scale doesn't forgive sloppiness. But it also rewards thoughtfulness in a way that smaller contexts often can't demonstrate. That's what made working on this product genuinely worthwhile.

Marcus

Marcus Bass

AI · Career Q&A

get in touch