Are events only used for GUI programming?

Nope. They're really handy for implementing Observers and making sure that classes are closed to modification.

Let's say we have a method that registers new users.

public void Register(user) {
    db.Save(user);
}

Then someone decides that an email should be sent. We could do this.

public void Register(user) {
    db.Save(save);
    emailClient.Send(new RegistrationEmail(user));
}

But we've just modified a class that's supposed to be closed to modification. Probably fine for this simple pseudo-code, but likely the way to madness in production code. How long until this method is 30 lines of code that's barely related to the original purpose of creating a new user??

It's much nicer to let the class perform its core functionality and to raise an event telling whoever's listening that a user was registered, and they can take whatever action they need to take (such as send an email).

public void Register(user) {
    db.Save(user);

    RaiseUserRegisteredEvent(user);
}

This keeps our code clean and flexible. One of the often overlooked pieces of OOP is that classes send messages to each other. Events are these messages.

Nope.

A classic example of events being used in non-GUI logic are database triggers.

Triggers are code that gets executed when a given event happen (INSERT,DELETE, etc). Seems like an event to me.

This is the Wikipedia definition of event:

In computing, an event is an action or occurrence recognized by software that may be handled by the software. Computer events can be generated or triggered by the system, by the user or in other ways. Typically, events are handled synchronously with the program flow, that is, the software may have one or more dedicated places where events are handled, frequently an event loop. A source of events includes the user, who may interact with the software by way of, for example, keystrokes on the keyboard. Another source is a hardware device such as a timer. Software can also trigger its own set of events into the event loop, e.g. to communicate the completion of a task. Software that changes its behavior in response to events is said to be event-driven, often with the goal of being interactive.

Not all events are user-generated. Some are generated by a timer like a crontab of by a database INSERT like I mentioned before.

The definition also states than some programs or systems are "event-driven, often with the goal of being interactive", from which one can derive that the purpose or usefulness of events are not solely, but rather often, to provide interactivity (like GUIs although not necessarily GUIs, since CLI programs can also be interactive).

Event-based programming is actually also used for highly performant server programming.

At a typical server workload, much of the time processing a result actually comes from I/O. For example, pulling data off a (7200 RPM) hard disk drive can take up to 8.3 ms. For a modern GHz processor, that would equate to ~1 million clock cycles. If a CPU were to wait for the data each time (doing nothing), we would lose a LOT of clock cycles.

Traditional programming techniques get around this by introducing multiple threads. The CPU tries to run hundreds of threads concurrently. However, the problem which this model is that, each time a CPU switches thread, it requires hundreds of clock cycles to context switch. A context switch is when the CPU copies the thread-local memory into the CPU's registers and also stores the old thread's register/state into RAM.

Additionally each thread must use up a certain amount of memory for storing its state.

Today, there has been a push for servers which has a single thread, that runs in a loop. Then pieces of work are pushed onto a message pump, which acts as a queue for the single thread (much like on a UI thread). Instead of waiting for work to finish, the CPU sets a callback event, for things like hard disk drive access. Which reduces context switching.

The best example of such a server is Node.js, which has been shown to be able to handle 1 million concurrent connections with modest hardware, while a Java/Tomcat server would struggle at a few thousand.

Event Messages Gregor Hohpe.

Event Driven Architectures Gregor Hohpe.

SEDA architecture, Welsh, Culler, Brewer.

how do you handle in normal backend programming when something happens do this other thing?

Finite State Machine is one common approach

Given(State.A)
When(Event.B)
Then(State.C)
    .and(Consequences.D)

Events are also heavily used in network programming to avoid expensive busy-wait loops and instead provide a clean interface to know exactly when a certain operation is available(I/O, urgent data etc).

The basic idea is to provide the OS a set of sockets (i.e. network connections) to monitor for events, all of them or just some you're particularly interested in (data available for reading, for instance); when such activity is detected by the operating system on one of the sockets list, you will get a notification of the event you were looking for by the API that you'll then have to sort out where it comes from and act accordingly.

Now, this is a low-level view and abstract view, furthermore tricky to get to scale well. However there's plenty of higher level frameworks that deal with that in even a cross-platform fashion: Twisted for Python, Boost.Asio for C++ or libevent for C come to my mind.

In embedded systems, events occur during interrupts. There are many sources of interrupts, from timers to I/O.

Also, RTOS can have events too. One example is waiting for a message from another task.

Embedded systems are almost always inherently event-driven, even if they are not programmed explicitly as such.

These events come from things like hardware interrupts, button presses, period analog-to-digital readings, timer expirations, etc.

Low-power embedded systems are even more likely to be event-driven; they spend most of their time sleeping (CPU sleeping in a low-power mode), waiting for something to happen (that "something" is an event).

One of the most common and popular frameworks for event-driven embedded systems is the Quantum Platform (QP) (the QP also works under Linux, Windows and any unix-like OS.) State machines are a natural fit for event-driven programming, as the program is not "sequential" in the typical sense, rather, it is a set of "callbacks" that are invoked depending on the system state and current event.