Modern regex engines fall into two broad families with very different performance characteristics. A DFA, or deterministic finite automaton, runs in linear time, never backtracks, and supports every feature that can be expressed as a finite state machine. The catch is that DFAs cannot support backreferences, lookaround, or capturing groups in their pure form, which is why almost every production regex engine is NFA-based. PCRE, Python's re module, Java's java.util.regex, and JavaScript's engine all use NFA semantics, which means they support the full feature set but may backtrack, and that backtracking can in the worst case be exponential in the input length.
Catastrophic backtracking is the worst-case pathology of an NFA engine. It happens when a pattern has overlapping ways to match the same text, so the engine tries an exponential number of combinations before giving up. The classic example is (a+)+$ applied to a string of many as followed by a single non-a: each outer iteration can split the as into a different number of inner groups, and the engine tries them all. The pattern is technically correct but takes exponential time. The fix is to break the ambiguity: use a possessive quantifier a++ or atomic group (?>a+)+, which prevent the engine from giving back characters once consumed. Whenever you write a pattern with nested quantifiers over the same character class, ask whether the structure is truly unambiguous, and prefer possessive or atomic forms whenever it is.
Several practical habits keep regex fast and predictable. Compile patterns once with re.compile when you reuse them, rather than parsing the pattern string on every match. Avoid backtracking where you can: a negated character class like [^>]+ is much faster than .*? when you know the boundary character. Use lazy quantifiers only when you actually want the shortest match, and use possessive quantifiers or atomic groups whenever the structure allows it. Finally, when a regex becomes hard to read or its performance unpredictable, it is often a sign that a small parser written in your host language would be clearer and faster. Regex excels at small, well-defined matching problems; for anything larger, a real parser is almost always the better tool.