Middleware & System Architecture
DDS vs Zenoh, QoS, and monolith vs. multi-process robot architectures.
Why it matters in robotics
Middleware and architecture questions separate candidates who can "make a node publish" from those who can design a robust distributed robot. Interviewers probe whether you understand the ROS2 RMW abstraction (why ROS2 is middleware-agnostic), how DDS discovery and QoS actually behave on a real network, and the concrete tradeoffs between DDS, Zenoh, MQTT, and gRPC. Expect QoS-incompatibility debugging stories ("publisher and subscriber don't connect — why?"), questions on reliable vs best-effort and transient-local durability, and discovery-scaling pain at fleet size. Senior roles especially expect you to reason about latency, determinism, and failure modes rather than recite API calls.
Application focus
The same topic, tailored to the robot you're building. Your choice is remembered across the roadmap and every topic.
At a glance
The ROS2 RMW abstraction: application code talks to a client library, which calls the vendor-agnostic rmw interface; a pluggable rmw implementation maps to a concrete middleware (DDS or Zenoh) that serializes onto the wire.
What to study
- ✓The ROS2 RMW abstraction: how rcl/rclcpp/rclpy sit above the vendor-agnostic rmw interface, and how pluggable implementations (Fast DDS, Cyclone DDS, rmw_zenoh) are swapped via RMW_IMPLEMENTATION.
- ✓DDS internals and QoS: RTPS, distributed discovery, and the request-vs-offered compatibility rules for reliability, durability, deadline, and history.
- ✓Transport tradeoffs: UDP/RTPS vs shared-memory vs intra-process, and when node composition / component containers and lifecycle nodes are the right architectural choice.
- ✓Comparing DDS vs Zenoh vs MQTT vs gRPC, discovery scaling at fleet size, fault isolation, and security via SROS2 / DDS-Security.
Study by time budget
Pick the path that fits the time you have before your interview.