Radar

Systems Architecture @ Runway Avenue

4 min read

By: Prashant Mehta, 10/12/2025

Introduction

I think about how far we’ve come a lot. Seven months ago now, seven people came together on this project, in business, marketing, machine learning, backend, frontend, recruitment, and investor relations. The seven of us didn’t have a clue that our scrappy team would result in victories and mercies very quickly after arguing constantly about how we wanted this project to look. To understand our systems architecture, you almost have to be in the room and watch those scrappy kids argue for three hours until 1:00am at In-N-Out off of El Camino and Remington in the middle of the night. We’re very proud of the people we’ve become since then, Rachit Kumar and I have always had somewhat of a wild work chemistry. Both of us having a passion for creating robust systems; Arohan Deshpande and I having the same passion for creating beautiful products. Saketh Machiraju, being an excellent infrastructure engineer and the person who brought the actual system we’re about to discuss to life. This is the system that supports everything this team will build and has built:

Describing Anton: How our Kubernetes structure works

I’ll skip the lovely demonstration on Kubernetes, perhaps we’ll save that for another article, that itself is its own couple hours to fundamentally understand and tinker with. All you need to know is Kubernetes controls pods, and pods compose services within a namespace. Services interconnect via kube-proxy, and eventually what started as a garage startup becomes a living breathing machine capable of handling millions of requests every hour.

We’ve broken our cluster down into the following namespaces & sub-services:

  • pacific-coast/
    • faiss
      • Vector search solution, generates an ID based off an item_vec
    • memcached
      • KV Caching layer for all of our item data
  • product-backend/
    • salesforce-api
      • All pipes going from collected user data to Salesforce CRM, we host our own staging DB that then migrates clean data to Salesforce in object format
    • pacific-coast-api
      • For managing all of our storage handling, caching, retrieval, and writes
    • user-request-handler
      • For managing all requests users may have for pacific coast, models, etc.
  • models/
    • Everything in core-ml, contained in Triton
    • models-interface
      • Determines which requests hit which models
      • model_a
        • Does subjective feature extraction from various data sources
      • model_b1
        • Generates a series of items that pair with a given original item
      • model_b2
        • Takes a set of items and generates an outfit
      • model_c
        • Generates a prediction of how the user will perceive the given outfit / item
  • observability /
    • grafana
      • Dashboard, builds off of prometheus queries
    • mimir
      • Metrics Database, 1 year lake store is required
    • lighthouse
      • Integration point for Grafana, metrics, can be interfaced by MCP
  • security/
    • vault
      • HashiCorp Vault for secrets storage
    • cert_rotation
      • Lightweight, secure API for handling the rotation of certs from the server to external services and requesting changes within the 90 day period
    • secrets_handler
      • Lightweight interface for connecting services through temporary generated secrets

Now obviously this system itself will evolve and shape over time, as that happens this blog will be updated to match all the services we own and operate internally. A few services, like observability & vault will move to exist outside of the given namespace, and that means a few things for the long haul. Of course this means we’d be operating dozens of physical nodes, potentially four dozen or more VMs all connected to our large Kubernetes clustering but right now it’s just us, a single Cogent cabinet, and Anton. That’s pretty easy to do as well, we wouldn’t have to reconfigure much to get a separate cluster running based on our original namespace. There’s also sort of a direction and flow to these parts that connect to one another, which we’ll discuss as a function of backend and in each underlying part as it connects to the broader system.

Note: You’ll notice Postgres is missing, this will be further elaborated in k8s-namespace-structure as well as Production PostgreSQL at Runway Avenue so please read those if you haven’t already.

Graph View

Backlinks