Design the object model and core APIs for an in-process autocomplete engine backed by a prefix tree (trie). The engine ingests a stream of terms, each carrying a weight that reflects how often or how recently it has been chosen, and answers one question fast: given the characters typed so far, what are the best-ranked terms that begin with them?

Operating context. A single library embedded in a host app (a search box, a command palette, an editor). The caller inserts terms up front and keeps mutating them over the session: a term's weight rises when a user picks it, new terms appear, and some terms are removed. On every keystroke the host asks for the top K completions of the current prefix, ranked by weight (ties broken deterministically, e.g. lexicographically), where K is small (typically 5-10). Terms are short strings over a known alphabet; the working set is large enough that recomputing a ranked list by scanning every term per keystroke is too slow. One caller drives the engine, but the design should name where a concurrency boundary would go if reads and writes later overlapped.

Out of scope. Networking, sharding, or any multi-process deployment; persistence and load/save of the index to disk; fuzzy, typo-tolerant, or substring matching (prefix only); how raw weights are computed from user behaviour upstream; and the UI / rendering of the suggestion dropdown. Model the in-process object graph, not the app or service around it.

What to produce. The class hierarchy (the trie and its node, the engine facade, value objects such as a term-with-weight and a suggestion, and the ranking abstraction), the public API each class exposes, and the state transitions of a node (interior vs terminal, and what happens on removal). Be explicit about: how insert and prefix lookup walk the tree and their cost; how the top-K-by-weight query avoids scanning the whole subtree on every keystroke; how a weight update or a removal keeps any cached ranking correct; how the ranking rule (weight, then tie-break) sits behind a seam so it can change; and the memory cost of the node representation and how you would cut it.