•CASE STUDY

Enterprise Remote Browser Isolation System

4 min read·635 words·Advanced

Asked at

1 candidate report in Jul 2026

How to use this case study

SDE-2 / Mid

Explain running each browsing session in a disposable cloud container and streaming only safe output (pixels or sanitized content) to the user

SDE-3 / Senior

  • Go deeper on session orchestration and a warm pool of isolated nodes
  • The streaming protocol and latency
  • Input forwarding
  • File upload/download policies

Staff / Principal

  • Discuss scaling to many concurrent sessions
  • Cost
  • Multi-region placement for latency
  • The security boundaries and threat model

Problem RestatementProblem

Oracle asked: design a remote browser isolation (RBI) system for enterprises. Instead of loading websites directly on employees' laptops (where malicious code could infect the device), each browsing session runs in an isolated, disposable virtual node in the cloud. Only a safe stream (rendered pixels or sanitized page content) reaches the user's device. If a site is malicious, it only harms a throwaway container, never the laptop or the corporate network.

RequirementsRequirements

  • The user opens a website → it runs in a remote isolated browser → the user sees and interacts with it smoothly.
  • Isolation: one session per container or microVM, destroyed after use.
  • Low latency (feels like local browsing), video and audio support.
  • Policies: which sites are isolated (all, or only risky categories), whether file downloads and uploads, copy/paste and printing are allowed.
  • Thousands of concurrent sessions across regions. Audit logs.

ArchitectureArchitecture

Architecture diagram
%%{init: {"look":"handDrawn","handDrawnSeed":7,"theme":"base","fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","themeVariables":{"fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","fontSize":"16px","primaryColor":"#fff4e6","primaryBorderColor":"#1e1e1e","primaryTextColor":"#1e1e1e","secondaryColor":"#e7f5ff","tertiaryColor":"#ebfbee","lineColor":"#1e1e1e","textColor":"#1e1e1e","mainBkg":"#fff4e6","nodeBorder":"#1e1e1e","clusterBkg":"#f8f9fa","edgeLabelBackground":"#ffffff","classText":"#1e1e1e"}}}%%
flowchart LR
    U["User browser / agent"] -->|"URL request"| GW["RBI gateway - auth, policy"]
    GW --> ORCH["Session orchestrator"]
    ORCH --> POOL["Warm pool of isolated nodes (microVMs)"]
    POOL --> RB["Remote headless browser"]
    RB -->|"fetch web"| NET["Internet via egress proxy"]
    RB -->|"rendered stream (WebRTC / pixels or safe DOM)"| U
    U -->|"mouse, keyboard, scroll events"| RB
    RB --> FS["File sanitizer (CDR) for downloads"]
    GW --> LOG[("Audit logs")]

Deep Dive — Where the risky browser actually runsDeep dive

The whole product is "the untrusted page renders somewhere that is not the user's laptop". Where that somewhere is, and what happens to it afterwards, is the design.

Weak

A shared browser process per user

Run each user's session as a process on a shared isolation host.

Architecture diagram
%%{init: {"look":"handDrawn","handDrawnSeed":7,"theme":"base","fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","themeVariables":{"fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","fontSize":"16px","primaryColor":"#fff4e6","primaryBorderColor":"#1e1e1e","primaryTextColor":"#1e1e1e","secondaryColor":"#e7f5ff","tertiaryColor":"#ebfbee","lineColor":"#1e1e1e","textColor":"#1e1e1e","mainBkg":"#fff4e6","nodeBorder":"#1e1e1e","clusterBkg":"#f8f9fa","edgeLabelBackground":"#ffffff","classText":"#1e1e1e"}}}%%
flowchart LR
  U1["User A - malicious site"] --> H["Shared host"]
  U2["User B"] --> H
  H --> KERN["One kernel, one file system"]
  KERN --> ESC["Browser exploit escapes the process"]
  ESC --> OTHER["Reaches User B's session and cookies"]
  H --> PERSIST["Process reused - malware survives into the next session"]

Two failures. A browser exploit — the exact threat this product exists to contain — crosses into other users on the same host. And reusing the environment means anything dropped by one page is present for the next session.

Good

A container per session

Give each session its own container: separate file system and process namespace, dropped capabilities, no host credentials.

A genuine boundary, and containers share the host kernel. Browser exploits are routinely chained with kernel bugs, and the adversary here is a web page chosen by the attacker — this is the one workload where assuming the kernel holds is least safe.

Best

A microVM per session, from a warm pool, destroyed afterwards

Architecture diagram
%%{init: {"look":"handDrawn","handDrawnSeed":7,"theme":"base","fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","themeVariables":{"fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","fontSize":"16px","primaryColor":"#fff4e6","primaryBorderColor":"#1e1e1e","primaryTextColor":"#1e1e1e","secondaryColor":"#e7f5ff","tertiaryColor":"#ebfbee","lineColor":"#1e1e1e","textColor":"#1e1e1e","mainBkg":"#fff4e6","nodeBorder":"#1e1e1e","clusterBkg":"#f8f9fa","edgeLabelBackground":"#ffffff","classText":"#1e1e1e"}}}%%
flowchart LR
  GW["Gateway - SSO, policy: isolate or allow by URL category, group, risk"] --> ORCH["Session orchestrator"]
  ORCH --> POOL["Warm pool - pre-started microVMs, browser ready"]
  POOL --> VM["Firecracker microVM - own kernel"]
  VM --> NET["No access to the corporate network - egress only"]
  VM --> STREAM["Pixels / DOM stream to the user's browser"]
  VM -->|"session ends or idles out"| DESTROY["Destroyed - nothing carries over"]
  ORCH --> SCALE["Pool scaled per region by demand"]
  • A hypervisor boundary, not a namespace one. An exploit that escapes the browser lands in a kernel it has to escape again, and that kernel belongs to nobody but this session.
  • Destroy, never reuse. The node is discarded at session end or idle timeout, so persistence — the goal of most drive-by malware — is impossible by construction.
  • A warm pool is what makes it usable. Booting a microVM and a browser on demand would add seconds to every click; a pre-started pool, scaled per region, makes isolation invisible to the user. This is the detail that decides whether the product is adopted.
  • No path to the corporate network. The isolated browser reaches the internet, never internal services — otherwise it becomes a convenient pivot rather than a containment.

Only pixels or a sanitised DOM stream reach the user's device, so the untrusted page never executes there — which is the property the whole architecture is buying.

Scale and CostScale

  • Each session needs CPU, memory and a GPU or video encoder. Pack sessions per host, and autoscale host pools per region by time of day.
  • Idle sessions are suspended or terminated quickly, and per-tenant quotas apply.
  • Monitor the p95 input-to-display latency, stream quality, and node startup time.

Wrap-UpWrap-up

Route policy-selected browsing through a gateway to an orchestrator that hands each session a pre-warmed, fully isolated microVM running a remote browser, with egress only through a filtering proxy, and destroys it afterwards. Stream only safe output (encoded pixels via WebRTC, or sanitized page content), forward user input back, sanitize or block file transfers, place sessions near users, and autoscale warm pools per region while logging everything for audit.

More Case Studies

Frequently Asked Questions

What is the Enterprise Remote Browser Isolation System system design question?

Enterprise Remote Browser Isolation System is a system design interview question asked at FAANG companies. It covers security, distributed systems, scheduling, media streaming and tests your ability to design scalable, production-ready systems. InterviewSkool's breakdown walks you through requirements, API design, architecture, and trade-offs.

Which companies ask the Enterprise Remote Browser Isolation System question?

Oracle have reportedly asked variations of this question in system design interviews. The exact wording may differ, but the core design challenges remain the same.

How should I prepare for the Enterprise Remote Browser Isolation System interview question?

Start with the problem statement and scale estimates, then design the high-level architecture. Focus on the core components, data model, and API design. InterviewSkool's breakdown covers the full solution with mermaid diagrams and trade-off analysis to help you prep efficiently.

What level is the Enterprise Remote Browser Isolation System question?

This question is suitable for SDE-2, SDE-3, and Staff engineer interviews. The level guidance on this page provides specific tips for each level — SDE-2 candidates should focus on core architecture, while Staff engineers should discuss trade-offs, monitoring, and incremental rollouts.

Practice with a Mock Interview

Apply what you learned in a live system design mock interview with InterviewSkool's AI interviewer.

Start System Design Interview →