Caching User Organizational Affiliations

User organization labels represent frequently accessed data, making them ideal candidates for Redis caching. The List data structure is preferred over Set for this use case due to its underlying implementation combining compressed lists with doubly-linked lists, which provides better memory efficiency and faster read/write operations. While Sets offer natural deduplication through hash tables, the hash computation and collision resolution process introduces overhead. Additionally, Lists preserve insertion order, which can be beneficial for certain operations.

// Organization tags and personal tags form a many-to-many relationship with users
// List structure accommodates multiple entries, using rightPushAll for batch insertion
// To prevent duplicates from accumulating, clear the key before re-inserting
redisTemplate.opsForList().rightPushAll(cacheKey, organizationTags.toArray());

// Retrieval operation fetches all elements from index 0 to -1 (entire list)
// Redis stores binary data, requiring type conversion from Object to String
try {
    String cacheKey = USER_ORG_TAGS_PREFIX + userId;
    List<Object> cachedTags = redisTemplate.opsForList().range(cacheKey, 0, -1);
    if (cachedTags != null && !cachedTags.isEmpty()) {
        return cachedTags.stream()
                .map(element -> (String) element)
                .collect(Collectors.toList());
    }
} catch (Exception ex) {
    log.error("Error retrieving organization tags for user {}", userId, ex);
}
return Collections.emptyList();

Native Redis Operations with RedisCallback

Spring Data Redis provides high-level abstractions like opsForValue() and opsForHash(), which handle automatic serialization between Java objects and Redis-compatible byte arrays. However, these abstractions introduce minimal overhead and may not expose all Redis commands. RedisCallback offers direct access to the underlying RedisConnection, bypassing Spring's serialization layer. As a functional interface, RedisCallback requires implementing the doInRedis method, either through anonymous classes or lambda expressions.

// Count set bits in a bitmap using native connection
Long processedChunks = redisTemplate.execute(new RedisCallback<Long>() {
    @Override
    public Long doInRedis(RedisConnection connection) {
        return connection.bitCount(fileUploadKey.getBytes());
    }
});

// Equivalent lambda implementation for hash field counting
Long fieldCount = redisTemplate.execute(connection -> 
    connection.hLen("user:profile:12345".getBytes())
);

Chunked File Upload Tracking with BitMaps

Redis BitMaps provide an efficient mechanism for tracking file chunk uploads. Each bit in the bitmap represents a file chunk, where 1 indicates successful upload and 0 denotes pending status. This approach enables memory-efficient state tracking for large file uploads.

// Check if specific chunk has been uploaded
boolean chunkUploaded = redisTemplate.opsForValue().getBit(uploadTrackerKey, chunkPosition);

// Mark chunk as uploaded after successful transfer
redisTemplate.opsForValue().setBit(uploadTrackerKey, chunkPosition, true);

// Verify completion by counting uploaded chunks
Long completedChunks = redisTemplate.execute((RedisCallback<Long>) connection -> 
    connection.bitCount(uploadTrackerKey.getBytes())
);

// Compare with total required chunks to determine completion
if (completedChunks.equals(totalChunks)) {
    // Trigger file assembly process
}