tokio-rs/mini-redis

Incomplete Redis client and server implementation using Tokio - for learning purposes only

View on GitHub ↗Jump to charts ↓

Summary Information

Updated 46 minutes ago
Added to GitGenius on September 14th, 2026
Created on December 4th, 2019
Open Issues & Pull Requests: 25 (+0)
GitHub issues: Enabled
Number of forks: 585
Total Stargazers: 4,785 (+0)
Total Subscribers: 53 (+0)

Repository Insights (GitGenius)

Median issue/PR response: 3.9 hours
Mean response time: 2.3 days
90th percentile: 6.8 days
Tracked items: 3

Most active contributors

Sign in to see contributor activity.

Charts & Analytics

Fetching additional details & charts...

Issue Activity (beta)

Open issues: 1
New in 7 days: 0
Closed in 7 days: 0
Avg open age: 1,888 days
Stale 30+ days: 1
Stale 90+ days: 1

Recent activity

Opened in 7 days: 0
Closed in 7 days: 0
Comments in 7 days: 0
Events in 7 days: 0

Top labels

No label distribution available yet.

Most active issues this week

No issue events were indexed in the last 7 days.

Detailed Description

mini-redis is a learning-focused Redis client and server implementation built with Tokio for demonstrating asynchronous Rust patterns.

The project addresses the need for a comprehensible example of building a real-world Tokio application. Rather than implementing a complete Redis clone, mini-redis deliberately omits features that would not teach new concepts, keeping the codebase focused on demonstrating practical patterns. It implements a subset of Redis commands—PING, GET, SET, PUBLISH, and SUBSCRIBE—over the Redis wire protocol, providing both a server and client library alongside example executables and a CLI client for interaction.

mini-redis is explicitly not intended for production use and should not be adopted for that purpose. It serves developers learning Tokio who want to study how asynchronous patterns apply in a realistic context. The project demonstrates TCP server implementation with per-connection task spawning, graceful error handling, and asynchronous client library design. The README directs users needing a fully featured Redis implementation to use alternatives instead, making clear that feature requests driven by production requirements will not be accepted.

The project includes structured logging via the tracing crate and optional OpenTelemetry integration for sending traces to external providers like AWS X-Ray, Jaeger, or Prometheus, showing how observability fits into a Tokio application. Development activity shows consistent maintenance with regular updates to dependencies and code examples, indicating the project remains aligned with current Tokio best practices. The codebase receives refinements to keep examples idiomatic and functional across Tokio releases.