The Orca Platform: One Screen, One Door

A pathologist is the doctor who diagnoses disease by examining tissue under magnification. In Orca that tissue arrives as a whole-slide image (WSI): a single scan of a glass slide that is gigapixel — on the order of 100,000 × 100,000 pixels, far too big to open all at once. The entire product the pathologist uses is one screen: the gigapixel slide, the AI's annotations (marks the model drew on the tissue), and the tools to accept or edit them.

The slide pans and zooms like a map. Beside it sits a list of AI annotation classes with live counts — the pathologist can accept a class, edit a mark, or reclassify it. The same screen runs on a desktop, a laptop, or a tablet.

That single screen is the whole story. Everything in the rest of this course is the machinery that makes it feel instant.

The most important rule in the platform is a boundary: the pathologist's browser (the frontend) never reaches a database or a compute machine directly. It talks to exactly one thing — an API Gateway, a single network front door that receives every request and forwards it inward. Behind that door sits the backend core: one service that is the single entry point to all of Orca's data and logic.

So the flow is always the same shape. The frontend renders whatever the backend serves it; it asks the API Gateway; the gateway hands the request to the core; the core does the work and answers. One door in, one door out.

Because there is only one door, the backend controls both what the UI shows and where the data lives. The client stays deliberately dumb, and every request can be checked, scoped, and secured in one place instead of fifty.

Zoom out one level and Orca is just three subsystems. The Frontend is the renderer the pathologist sees. The Backend is the secure core plus the data it owns. The AI Services are the parts that actually run models — a workflow engine that chains steps together, and an inference service that runs the model on a GPU.

Everything the pathologist does crosses the API Gateway into the core; the core is what reaches the AI Services and the data stores. Nothing skips the core.

Three subsystems is the entire mental model. The next section fills in the real AWS pieces, but the shape never changes.

Here is the real architecture, the one from Orca's own engineering docs. The frontend web app reaches only the Backend Core, through the API Gateway. The core drives the Workflow Engine, which runs AI inference on an EC2 GPU machine (EC2 is AWS's rentable virtual server; a GPU is the specialized chip that runs the model). The core owns the data: application state lives in RDS MySQL (a managed relational database), and the slides and model files live in S3 (AWS's object storage — think a giant, cheap file bucket).

The one structural choice to notice: the AI Services sit on their own. The task-chaining Workflow Engine and the AI Inference Service are a separate tier, reached only through the core — never by the frontend.

This is the map to keep in your head for the rest of the course. Every later day is a zoom-in on one box here: the Frontend (Day 4), the Canvas inside it, the Backend Core, and the Workflow Engine that drives EC2.

Notice the dashed box in the map: the AI-model lifecycle is deliberately separate from the running platform. Building, registering, and managing models is its own job with its own cadence — research ships new models constantly — so it is not wired into the request path. It produces trained models; the inference service consumes them.

Keeping it apart means the platform that serves pathologists and the pipeline that produces models can each change on their own schedule without breaking the other.

The rest of the platform never has to know how a model was made — only that inference can load one by name. That separation is what lets the AI team and the platform team move independently.

Strip away the medical detail and this day is really about two design principles that carry the whole platform.

• One entry point. Because the frontend can only reach the API Gateway, and the gateway only reaches the core, there is exactly one place to enforce authentication, tenant isolation, and data access. A rule written once there applies everywhere — no endpoint can quietly forget it.
• Separate what changes at different speeds. The Frontend, the Backend, and the AI Services each move on their own clock. Drawing them as three subsystems with clean seams (the gateway, the core's calls into the AI tier, the model lifecycle) means a change in one rarely forces a change in another.

Hold this map. From here on, every deep dive is just one of these boxes opened up.

• Orca is one screen for the pathologist: a gigapixel whole-slide image, AI annotation classes with live counts, and the tools to edit them — on desktop, laptop, or tablet.
• The frontend talks to exactly one thing, the API Gateway, which forwards to one Backend Core. The client never touches a database or compute directly.
• The platform is three subsystems: Frontend (renderer), Backend (secure core + data), and AI Services (workflow engine + inference). Everything funnels through the core.
• On AWS: the core drives the Workflow Engine, which runs inference on an EC2 GPU; state lives in RDS MySQL and slides/model files live in S3.
• The AI Services are a separate tier reached only through the core, and the AI-model lifecycle (build, register, manage) is separate again — each moves on its own schedule.
• One door means one place to enforce security and isolation; three clean subsystems mean each can change without breaking the others.

• [ ] I can describe the one screen a pathologist uses and name what is on it.
• [ ] I can state the single boundary: the frontend talks only to the API Gateway, which reaches only the Backend Core.
• [ ] I can name the three subsystems and say what each is responsible for.
• [ ] I can draw the AWS map: frontend → API Gateway → core → { workflow engine → EC2 inference, RDS MySQL, S3 }.
• [ ] I can explain why the AI Services and the AI-model lifecycle are kept separate from the request path.
• [ ] I can give the two engineering principles: one entry point, and separating parts that change at different speeds.