...

For queries contains dynamic parameters it need to have a possibility to map partition aware involved columns into direct node. Let`s use some kind of piggybacking (or probably lazy) approach to delivery such a mapping i.e. lets send first request(s) into any possible node (as it was without partition awareness implementation) and obtain such mapping with first response. In the case when query response contains partition aware metadata it need to be cached directly into size bounded
Map<PaCacheKey, PartitionAwarenessMetadata> structure where PaCacheKey represents schema and query with additional pre-calculated hash for further comparing boosting. It's worth mentioning that such approach will give different resolving for equivalent queries like:

...

CREATE TABLE T (
    id int, 
    col1 int DEFAULT -1,
    col2 int, 
    PRIMARY KEY(id, col1, col2)) 
    COLOCATE BY(col1, col2)
)

//  Colocation column values passed via params
INSERT INTO T (id, col1, col2) VALUES(1, ?, ?);

// Colocation column values partially passed via literals
INSERT INTO T (id, col1, col2) VALUES(1, ?, 100);
INSERT INTO T (id, col2) VALUES(?, 100), (?, 200);

Risks and Assumptions

// Describe project risks, such as API or binary compatibility issues, major protocol changes, etc.

...