Let's simplify the problem. We are building a simplified in-memory version of Zookeeper. Zookeeper is a distributed coordination service. At its heart, it's a hierarchical key-value store (like a file system) that maintains configuration information, naming, providing distributed synchronization, and group services. Our simplified version will focus on the core functionalities:

1. Data Model: A hierarchical namespace, much like a file system. Each node in the namespace is called a znode. Znodes can have data associated with them (a byte array).
2. Session Management: Clients establish sessions with the Zookeeper service. Sessions have a timeout. If a client doesn't send heartbeats within the timeout, the session expires.
3. Persistent and Ephemeral Nodes: Znodes can be persistent (they exist until explicitly deleted) or ephemeral (they are automatically deleted when the session that created them expires).
4. Watches: Clients can set watches on znodes. A watch is a one-time trigger. When the znode changes (data changes, child nodes added/removed, or the znode itself is deleted), the watch is triggered, and the client is notified. The watch is then removed.
5. Concurrency: Handle concurrent client requests safely.

This problem requires a robust object-oriented design that prioritizes maintainability, extensibility, and thread safety.

Requirements