Design resource loader and ROS-like pub/sub

HardSoftware Engineer Onsite System Design

Last updated October 28, 2026

This question evaluates system design and distributed-systems competencies including resource management, async concurrency, caching and eviction, streaming and partial loads, dependency resolution, failure isolation, observability, and pub/sub concerns such as topic/schema/versioning, discovery, QoS, ordering, replay, partitioning, latency, clock semantics, and security. Commonly asked to assess architectural reasoning about scalability, low-latency trade-offs, fault tolerance, and deployment/topology choices, it is categorized under System Design and tests both high-level conceptual understanding and practical application-level design decisions; English.

Part A – Design a Resource Loader that supports multiple resource types (e.g., images, configs, ML models). Specify the public APIs, how new types are plugged in, async/concurrent loading, prioritization, batching, caching (memory/disk), eviction, deduplication, retries/timeouts, dependency resolution, streaming/partial loads, failure isolation, thread-safety, and observability (metrics/logging/tracing). Discuss deployment, scaling, and trade-offs. Part B – Design a ROS-like publish/subscribe system. Define topics, message schema/serialization, discovery, QoS/reliability options (best-effort vs. reliable), ordering, replay/durability, backpressure and flow control, handling slow or disconnected subscribers, partitioning and scaling across nodes, latency/real-time considerations, clock synchronization, fault tolerance, and security (authn/z, encryption). Compare brokered vs. brokerless and federated topologies and justify your choices.