The snippets, ordered obscure → unmistakable

  1. Snippet 1(Common hashing helper)
  2. Snippet 2(ae event loop)
  3. Snippet 3(object encoding tags)
  4. Snippet 4(command table entry)
  5. Snippet 5(RDB persistence)
  6. Snippet 6(ascii art banner — server.c)

Why this project gives itself away

The give-away. Snippet 1's siphash for hash-table key mixing is a strong signal — Redis adopted SipHash in 5.0 specifically to mitigate hash-flooding. Snippet 2 reveals ae, Redis's hand-rolled event loop with kqueue/epoll backends. Snippet 3 names the type tags (OBJ_ZSET, OBJ_STREAM) — recognisable to anyone who's debugged a TYPE response. Snippet 4 is the command table with attribute strings like "write use-memory @string"; this is unmistakable Redis. Snippet 5's rdbSaveBackground + redisFork is the famous fork-and-COW persistence model. Snippet 6 is the dead give-away: the ASCII-art logo Redis prints on every server boot.

How a Framed puzzle is built

Every Framed project ships exactly six snippets, hand-ordered from deeply obscure to unmistakable. The first snippet must be plausible for a dozen codebases — a generic loop, a small utility, a comment that could appear anywhere. The last snippet carries a project-specific tell: a function name, a code-comment idiom, a file header, a build invocation. Between them sit four snippets that gradually narrow the field. Reading them in order is half the puzzle: a returning Framed player learns to triangulate on indentation conventions, comment voice, naming, and the small-but-distinctive choices that betray a project's era and community.

↳ redis/src/server.c structure and the ASCII banner.