Architecting dynamic audio streaming application

I’m planning to develop a simple application that works as a radio station, streaming some random music on a React Native app. Every hour or so, after a track ends, a custom audio track should be played on the stream based on the user location.

I’d like to keep most of the logic within the server-side, and have the app only to stream this station, and send data to the server so it can change the content being streamed. It also should support multiple users at the same time. So, besides the geographical coordinates, we should have the user id (all users must be logged in to access the streaming) sent as well.

Also, it’s necessary to track the state of the audio stream to keep a log of how many minutes the user actually played the stream and also to log if the specific tracks were delivered to the user. It means every time the user start or stop the streaming, the server must be aware of that.

I never worked with media streaming before, much less collecting data from it. That’s the reason why I’m requesting the help of more experienced developers on this area to make good decisions in terms of architecture to keep if as efficient as possible.

Here are one idea that I got to make this work. However, I’m quite sure there is a better way to do it:

1- The Youtube Style:

My first idea would have the app to send a request to an API endpoint like /playMusic, containing the user_id, timestamp and location_data and have its response a URL of the audio stream of a single track. On the mobile app, we detect when it the track has ended, and we do another request to get another song. In the server side, we check if it’s the proper time and location to play the custom audio track, if so, we have it send the URL for this specific track, otherwise, just send the URL of the next song. If the player state changes to PAUSE or STOP, we can can send a request to the server with to have the state logged and calculate the total playing time and other metrics by doing calculations with timestamp. There is a very serious problem with this: if the device runs out of battery, or the user closes the app forcefully, the state won’t be updated in the server, and it will count as it was playing forever. One workaround would check the absence of request to get another song.

I’ll probably use S3 and CloudFront to deliver the content.

Any feedback would be appreciated, it would be awesome if you guys could provide some insights on the best way to do it and/or foresee some issues with the implementation.