Devlog: Building SSSocks — Days 1 to 6: Infrastructure to Atomic ReservationsFirst devlog for SSSocks, a high-performance e-commerce backend for premium sock sales. This log covers architecture choices, infrastructure setup, and technical challenges from the first six phases of development.Days 1–2: Infrastructure and CI/CD AutomationThe project focused on isolating the execution environment to ensure consistency across hosts.Configured a local development stack using Docker Compose (PHP-FPM, Nginx, and MySQL).Established an automated CI/CD pipeline using GitHub Actions.Integrated PHPStan for static analysis at Level 8 to enforce strict typing and prevent runtime type mismatches.Day 3: Database Schema and MigrationsDatabase modifications were abstracted using migrations to manage state deterministically.Integrated Phinx for migration and seeding management.Executed the initial relational schema, creating the products table.Implemented core database fields: unique stock keeping units (sku), names, inventory counts (stock), and prices stored as integers representing cents to avoid floating-point inaccuracies.Day 4: Dependency Injection and RefactoringAs the codebase scaled, manual object instantiation was replaced with a cleaner design pattern.Integrated the Nette DI container to manage object lifecycles and decouple classes.Configured service definitions inside config/common.neon.Refactored components like PasswordManager into standalone services managed by the container.Day 5: Presentation Layer and Repository PatternSeparated data access from presentation logic to maintain clean boundaries.Implemented the Repository pattern with ProductRepository handling data retrieval via Nette Database Core.Created ProductSeeder via Phinx to populate the database with standardized test inventory.Integrated the Latte template engine, eliminating inline HTML concatenation and establishing an MVC separation for the product showcase.Day 6: Highload Optimization and Race Condition PreventionThe standard SELECT stock -> UPDATE stock workflow introduces race conditions under concurrent traffic, causing overselling. To achieve atomic inventory reservation under high load, the architecture was refactored:Introduced a Redis instance running on an Alpine image inside the Docker network.Developed a StockManager service acting as an abstraction layer over the Redis memory cache.Wrote an embedded Lua script executed directly inside the single-threaded Redis engine. The script performs read, condition-check, and decrement operations atomically within a single non-blocking transaction.Lualocal current_stock = tonumber(redis.call(‘GET’, KEYS[1]))
if current_stock and current_stock >= tonumber(ARGV[1]) then
redis.call(‘DECRBY’, KEYS[1], ARGV[1])
return 1
end
return 0
Technical Challenges and Bug FixesPSR-4 Case Sensitivity: Encountered class-loading failures during Linux-based CI execution despite code running successfully on a Windows host. Resolved by aligning file naming conventions with uppercase namespaces (Bootstrap.php and StockManager.php).Docker Network DNS Propagation: Encountered a Name or service not known error connecting the PHP container to the new Redis host. Solved by flushing the virtual network topology via docker-compose down && docker-compose up -d.Strict Parameter Compliance: PHPStan Level 8 rejected passing integer parameters into the Predis eval method arguments. Fixed by explicitly casting inventory quantities to strings: (string) $quantity.Current Backlog[ ] Implement an API endpoint structure to accept incoming product selections.[ ] Integrate a validation layer for incoming HTTP POST request payloads.[ ] Design the architecture for the stateful shopping cart session.
