Ordinarily my initial reaction would be to allow undefined for properties like that, and do the default handling whereever the value is needed, but you’ve given a pretty pathological example here, because the default wouldn’t be the same at access time. If there is a registration bottleneck, such as registerNewServer in ServerService, I guess I would consider adding it there if needed. As far as TypeScript syntax goes, I make liberal use of optional properties (foo?: string) so that object literals don’t have to provide everything to be copacetic.
That sounds like a great use case for RxJS in general, because you can hide a lot of complexity behind a single Observable<Song[]>, that clients need know absolutely nothing about the details of, such as a lazily-fetched cache with periodic polling or push notification. All of that can be added progressively if needed by just modifying stuff inside ServerService, with zero impact on client code.
Fair concern, and something worth keeping in the back of your head. I’ll put it this way: I find myself more often merging several little services than splitting up big ones, and it’s irritating when I have to hunt around a bunch of little classes to find bugs that live in the crevices between them.