Build fluency in full-text and vector search with the Redis search module.
0 / 5 completed
1 / 5
At standup, a dev sets up a full-text index in Redis. Which command creates it?
FT.CREATE defines a search index over Redis hashes or JSON, specifying fields and their types. It is the entry point for RediSearch. Once created, indexed documents become queryable.
2 / 5
During a design review, the team must choose field types for a status filter vs. a body search. Which mapping is right?
Use a TAG field for exact-match, low-cardinality values like a status, and a TEXT field for tokenized full-text search like a body. TAG avoids tokenization and supports precise filters. Choosing correctly affects both correctness and performance.
3 / 5
In a code review, a dev adds similarity search over embeddings. Which field/query type fits?
RediSearch supports a VECTOR field for embeddings and KNN queries to find nearest neighbors. You specify the distance metric and dimensionality at index creation. This enables semantic search inside Redis.
4 / 5
An incident report shows the team needs grouped, aggregated analytics over search results. Which command fits?
FT.AGGREGATE runs a pipeline of grouping, reducing, and transforming over matched documents. It goes beyond plain FT.SEARCH for analytics-style queries. Use it for counts, sums, and projections.
5 / 5
During a PR review, a dev queries a TAG field but gets tokenized matches. What is the likely mistake?
Tokenized matches on what should be exact filters indicate the field was declared TEXT instead of TAG. TEXT applies tokenization and stemming, while TAG matches whole values. Re-declaring the field as TAG fixes the filter behavior.