FYI, a headless service can coexist with other types of services, such as loadBalancer. Simply create an additional service with a different name and the same selector.

The more idiomatic way to do this is to change your pod3 application to handle outages of your DB and API servers. (Applications should not crash or become unusable just because the DB or other is temporarily unreachable.) I realize this is not so easy in some applications, (eh-hem, Ruby on Rails, eh-hem,) in those cases you can write an entrypoint (E.G. bash script) for the pod3 container, and that entrypoint simply loops until it can reach the other two services, then uses exec to replace the process and initialize the pod3 app. I have implemented this and it works very well. Here's a simplified example from memory:

#!/bin/bash

while ! $(mysqladmin ping); do
  sleep 2
done

exec node app.js
# Or exec whatever arguments were passed to the container init.
# exec $@

Whether you can improve your app or or have to use a custom entrypoint, the same code that would check the reachability of pod2 and pod1 can be added as a k8s readinessProbe on the pod3 container. - This will ensure pod3 is removed/not added as an endpoint to your service until the readinessProbe passes. Obviously this only helps if your app waits to receive requests before reaching out to it's dependencies.

Note: all this holds true if you were to swap the pod abstraction for the container abstraction, I.E. 3 containers in one pod.

statefulSets create near replicas of the same pod definition, so this is not the abstraction you want. Instead I would use a distinct statefulSet for your DB service, (to ensure it gets shutdown down before being started elsewhere,) and 2 distinct deployments for your API server and app, and configure them in such a way that init order does not matter, as suggested above.