When a 'shell script' is executed, it's executed with the permissions of the user that executed that script. Most services (kafka, redis, nginx, etc) installed using a package manager (yum, apt, etc) install helper scripts to facilitate the control of those services, and create unique service users associated with those services (apache, redis, nginx, etc.) Nearly all of these helper scripts are executed as root initially, and then drop privileges to a service user assigned to that service. This ensures that only authorized users (i.e. users who are authorized to execute "sudo service kafka start") can effectively control those services. This means sysadmin Sally can start, stop, and restart kafka and nginx, while developer Jim may be restricted to only starting and stopping kafka (or some such.) While a java user may be created by the administrator, it's not something I've seen in practice, any more than a ruby user or a python user. Rather, the service ownership is more often pinned to a service user related to that particular service.
Some processes depend on being run as root (usually the ssh server daemon is run as root.) Other processes will refuse to start as root (postgresql is one.)
If you review a helper script for a service at /etc/init.d/someservice (or /etc/init/someservice.conf) the actual scripting that causes privilege escalation or drops are coded there. Alternatively, if you're logged in as user stephan, and execute something like /usr/sbin/redis-server -c /etc/redis.conf, then check on that process from another window, you'll see that redis is owned by stephan.
Hope that helps.