Mobi: Microservices

Mobi is a complex image analysis platform. To handle heavy computational loads (like SAM segmentation) without blocking the UI, we use an asynchronous microservices architecture.

The system is containerized with Docker, orchestrated via Docker Compose, and relies on a message broker pattern.

Each service runs in its own isolated container. We use multi-stage builds to keep image sizes small (e.g., stripping build tools from the final Python image).

When a user requests a segmentation, the FastAPI backend doesn't process it immediately. Instead, it pushes a job to Redis.

Specialized Celery Workers (CPU for logic, GPU for inference) pick up these jobs. This decouples the HTTP request/response cycle from heavy processing.

We use PostgreSQL for structured data. Complex spatial queries are optimized using indices.

Mobi uses Meta's Segment Anything Model (SAM) for AI-powered image segmentation. Running inference on a GPU is expensive — the architecture separates embedding generation from prediction and caches embeddings in Redis so repeated interactions on the same image do not recompute from scratch.

When a user uploads an image, a Celery GPU worker loads SAM using sam_model_registry, a registry pattern that maps model variant names (e.g., "vit_h") to constructor functions. The model loads once per worker and is cached globally — subsequent calls return the cached predictor immediately.

After the model is ready, a second Celery task generates image embeddings. predictor.set_image() converts the image into a high-dimensional feature representation. These features (predictor.features) are serialized and written to Redis with a 1-hour TTL. The main service polls Redis until embeddings appear before dispatching the prediction task.

Rather than polling the server for task completion, Mobi uses WebSocket connections to push notifications to the browser the moment a background job finishes. The scope is intentionally narrow: the WebSocket channel carries notification events only, not live data streams.

ConnectionManager maintains a registry of active WebSocket connections keyed by user ID. A Dict[str, List[WebSocket]] structure allows a single user to have multiple simultaneous connections (e.g., multiple browser tabs) — each tab receives the notification. An asyncio.Lock() prevents concurrent modification of the registry.

When a Celery task completes, NotificationService.create_and_dispatch() persists a Notification row to PostgreSQL first, then calls manager.send_personal()to fan out to all of the user's connected clients. The persistence-first pattern ensures notifications survive page refreshes — the frontend can re-fetch missed notifications on reconnect.

The Mobi frontend is a multi-panel workspace where every pane can be dragged, resized, and rearranged. Rather than building custom drag handlers, the app delegates this entirely to react-mosaic-component — a tiling window manager for React.

LayoutManager is a thin controlled wrapper. It receives layout (the current tile tree), renderTile (how to render each view), and onChange (a callback when the user repositions a panel). The underlying Mosaic component handles all hit-testing, pointer events, and animation. Panels can be resized down to 1% of available space via minimumPaneSizePercentage.

The bottom toolbar uses Material-UI icons — pre-built accessible SVG components imported by name. Each panel type maps to a semantic icon: a ruler for the measurement tool, a clipboard for tasks, a chart for results. No hand-drawn SVGs or custom paths are needed.