Mostly they just aren’t a problem. If you write a function A that calls some function B that doesn’t exist yet, you might get a warning. It’ll say something like “B is not known to be defined”. But the key thing to remember is that it doesn’t really care about B yet, not until you actually call A. Only then will it resolve B, checking to see if it is a real function or not, and then call it or error out.

But since most people get annoyed by warnings, they would ensure that A and B are in the same file. JDRiverRun also suggests using decare-function. If you read the docstring for that (using C-h f), you‘d get a link to chapter 13.16 Telling the Compiler that a Function is Defined of the Emacs Lisp Manual which describes some of the scenarios where it is useful.

As elisp is a dynamic language, it looks up these functions when needed. You can try it: E.g., evaluate this in the scratch buffer (C-x C-e):

(defun testfn1 ()
  (testfn2 "Test123"))

This works even though testfn2 is not defined. However, evaluating (testfn1) (actually calling the function) will give you an error as testfn2 is not found.

When you define testfn2, it is added to the global scope and thus becomes available for testfn1.

(defun testfn2 (text)
  (message "Msg: %s" text))

Now, (testfn1) works.

You can even define a new version of testfn2 which does something different. This way you can change any function in a lisp environment (this generally applies for scripting languages). This way also circular references are no problem. There may be warnings, when byte compiling functions with undefined references, but these are just warnings and compiling still works. If you look at a byte-compiled elisp file, you still see symbolic references to the called functions.