Toonily
Backend & Platform Engineering
Toonily is a large-scale webtoon and manga-reading platform developed and maintained by our team. The platform originally relied on a combination of Node.js and PHP, with PHP powering much of the content-management system while Node.js handled API endpoints, background jobs, and real-time features. As the platform grew, increasing traffic, high image-request volumes, memory-intensive background jobs, and duplicated business logic created performance and maintainability challenges. Our team gradually introduced Go services to modernize the most performance-sensitive parts of the backend without replacing the entire platform at once.
Technologies
Team
Backend, Frontend, DevOps and Editorial teams
Timeline
Long-term
Challenges
The challenges
Chapter pages generated a very large number of image requests.
Traffic increased significantly whenever new chapters were released.
Some background jobs consumed excessive amounts of memory.
Business logic was duplicated across PHP and Node.js services.
The growing backend became harder to test, maintain, and extend.
Image-heavy workloads created additional pressure on the application and storage infrastructure.
Solutions
How we approached it
Gradually introduced Go services for performance-sensitive workloads.
Used Redis to cache frequently requested chapter information.
Moved intensive image-processing workloads into dedicated Go workers.
Introduced Kafka-based asynchronous job processing.
Applied an incremental migration strategy instead of rewriting the entire platform.
Kept the existing PHP CMS in place while integrating new Go services behind internal APIs.
Optimized uploaded images and converted them into more efficient formats such as WebP.
Separated content management, API delivery, background processing, storage, and CDN responsibilities into dedicated services.
Features
What we built
Chapter Delivery API
Our team developed a Go-based chapter delivery service responsible for retrieving chapter metadata, validating access, generating ordered image URLs, and returning reader configuration to the frontend.
Image Processing Pipeline
Dedicated background workers handle image validation, thumbnail generation, image-format conversion, metadata extraction, and CDN cache invalidation.
Chapter Import
An asynchronous processing pipeline handles uploaded chapters and moves them through validation, processing, storage, and database updates.
Redis Caching
Frequently accessed chapter information is cached in Redis to reduce repeated database queries and improve response times.
CDN & Object Storage
Processed chapter assets are stored and delivered through object storage and CDN infrastructure designed to handle large volumes of image traffic.
Background Processing
Heavy operations are processed asynchronously so that image processing and chapter-related workloads do not block user-facing requests.
Architecture
Chapter Delivery Flow
When a reader opens a chapter, the request passes through the CDN and reaches the Go chapter API. The service checks Redis for cached chapter information and falls back to the primary database when necessary. The resulting chapter data and ordered image URLs are then returned to the frontend.
User
The reader opens a chapter.
CDN / Cloudflare
Handles traffic distribution, caching, and asset delivery.
Go Chapter API
Handles chapter access, metadata retrieval, reader configuration, and image URL generation.
Redis
Provides cached chapter information for frequently requested content.
MySQL / PostgreSQL
Stores application, chapter, and metadata information.
Object Storage / Image CDN
Stores and delivers processed chapter images.
Team
Our work
Designed and developed backend services as a team.
Migrated selected performance-sensitive workloads from Node.js and PHP to Go.
Developed and maintained chapter delivery services.
Implemented caching strategies using Redis.
Built background processing workers for image-related workloads.
Integrated asynchronous processing through Kafka.
Implemented image validation, optimization, and WebP conversion.
Integrated object storage and CDN infrastructure.
Maintained integration with the existing PHP-based CMS.
Improved the architecture and maintainability of backend services.
Worked across backend, infrastructure, storage, and content-processing layers.
Results
Outcomes
Improved concurrency for high-traffic chapter delivery workloads.
Reduced memory consumption for selected background-processing workloads.
Separated intensive image processing from the main application.
Reduced duplicated business logic across backend services.
Improved the scalability and maintainability of the platform.
Improved the efficiency of image storage and delivery.
Enabled gradual modernization without requiring a full platform rewrite.
Created a foundation for further migration and scaling of the platform.