Doctrine Key Value Storage Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Use Case Alignment: The bundle provides a typed key-value storage layer within Doctrine ORM, which is ideal for:
  • Caching transient data (e.g., API responses, session-like state) without polluting the main entity model.
  • Storing metadata (e.g., user preferences, feature flags) with strong typing (e.g., int, string, bool).
  • Replacing simple Redis/Memcached use cases where persistence is required but complex queries aren’t needed.
• Doctrine Integration: Leverages Doctrine’s existing infrastructure (e.g., EntityManager, Connection), reducing boilerplate for CRUD operations.
• Limitations:
  • Not a replacement for dedicated KV stores (e.g., Redis) for high-throughput scenarios.
  • No built-in TTL or eviction policies (must be managed manually via Doctrine lifecycle callbacks).
  • No distributed consistency guarantees (single-node DB dependency).

Integration Feasibility

• Laravel Compatibility:
  • High: Laravel’s Doctrine Bridge (laravel-doctrine/orm) can integrate this bundle with minimal friction.
  • Dependencies: Requires Doctrine DBAL/ORM (v2.10+), which Laravel can support via doctrine/dbal and doctrine/orm.
  • Conflict Risk: Low if the project already uses Doctrine; otherwise, adds complexity.
• Database Support: Works with any Doctrine-supported DB (MySQL, PostgreSQL, SQLite, etc.).
• Schema Migrations: Requires a custom table (e.g., key_value_store) with columns for key, value, type, and optional metadata.

Technical Risk

Key Questions

1. Why Doctrine?
   • Is the goal to avoid external dependencies (e.g., Redis) or leverage existing DB infrastructure?
   • Would a hybrid approach (Doctrine for persistence + Redis for caching) be better?
2. Data Model Design
   • How will keys be namespaced to avoid collisions (e.g., user:123:preferences)?
   • What’s the maximum value size (e.g., 64KB vs. 1MB) and how will it be enforced?
3. Performance SLAs
   • What are the read/write latency targets? (Doctrine may add 5–50ms overhead vs. Redis.)
   • Are there hot keys that could cause DB contention?
4. Maintenance
   • Who will own schema migrations if the bundle evolves?
   • How will backups be handled (e.g., included in existing DB backups)?
5. Alternatives
   • Could Laravel’s cache drivers (e.g., database driver) or Eloquent accessors suffice?
   • Is there a custom solution (e.g., a simple KeyValue table) that’s simpler?

Integration Approach

Stack Fit

• Laravel Ecosystem:
  • Doctrine ORM: Required for the bundle to function. If not already in use, adds ~50MB to dependencies.
  • Database: Must support Doctrine’s schema tools (e.g., MySQL 8.0+, PostgreSQL 12+).
  • Caching Layer: Could complement (not replace) existing Redis/Memcached for hot data.
• Non-Laravel Dependencies:
  • PHP 8.1+: Required for latest Doctrine features (e.g., typed properties).
  • Composer: Standard for PHP package management.

Migration Path

1. Assessment Phase:
   • Audit current key-value usage (e.g., Redis, config files, Eloquent serialize columns).
   • Identify candidate data for migration (e.g., low-churn metadata).
2. PoC Implementation:
   • Add bundle via Composer:

     composer require dontdrinkandroot/doctrine-key-value-storage-bundle
     

   • Configure in config/packages/doctrine_key_value_storage.yaml:

     doctrine_key_value_storage:
         table_name: 'key_value_store'
         columns:
             key: 'string'
             value: 'text'
             type: 'string'
     

   • Create a migration for the storage table:

     use Doctrine\Migrations\AbstractMigration;
     use Doctrine\DBAL\Schema\Schema;
     
     class Version20230101000000 extends AbstractMigration
     {
         public function up(Schema $schema): void
         {
             $this->addSql('CREATE TABLE key_value_store (
                 id INT AUTO_INCREMENT PRIMARY KEY,
                 key VARCHAR(255) NOT NULL,
                 value TEXT NOT NULL,
                 type ENUM("string", "int", "bool", "json") NOT NULL,
                 created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
                 updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
                 UNIQUE KEY unique_key (key)
             )');
         }
     }
     

3. Phased Rollout:
   • Phase 1: Migrate non-critical key-value data (e.g., feature flags).
   • Phase 2: Replace simple Redis usage (e.g., rate limiting counters).
   • Phase 3: Evaluate performance impact under load.

Compatibility

• Doctrine Version: Tested with Doctrine ORM 2.10+. Ensure Laravel’s Doctrine Bridge is compatible.
• Database Dialects: Verify support for the target DB (e.g., PostgreSQL’s jsonb vs. MySQL’s json).
• Existing Code:
  • Breaking Changes: None expected, but key-value access patterns may need refactoring (e.g., KeyValueStore::get('key') vs. Redis::get('key')).
  • Fallbacks: Implement circuit breakers for critical paths (e.g., retry with Redis if Doctrine fails).

Sequencing

1. Infrastructure:
   • Upgrade PHP to 8.1+ and Doctrine to latest stable.
   • Ensure DB supports JSON columns (if storing complex types).
2. Development:
   • Create a wrapper service to abstract the bundle (e.g., KeyValueService):

     class KeyValueService {
         public function __construct(private EntityManager $em) {}
     
         public function get(string $key, string $type = 'string'): mixed {
             $repo = $this->em->getRepository(KeyValue::class);
             $item = $repo->findOneBy(['key' => $key]);
             return $item ? $item->getValue($type) : null;
         }
     }
     

3. Testing:
   • Unit Tests: Mock KeyValue entity and EntityManager.
   • Integration Tests: Test with a real DB connection and verify migrations.
   • Load Tests: Simulate 10K writes/sec to identify bottlenecks.
4. Deployment:
   • Blue-Green: Deploy to a staging environment with the new bundle alongside old systems.
   • Feature Flags: Use Laravel’s config or environment variables to toggle the new store.

Operational Impact

Maintenance

• Schema Management:
  • Pros: No external service to patch/update.
  • Cons: Manual migrations required for bundle updates (e.g., adding new columns).
  • Tooling: Use Doctrine Migrations or Laravel Migrations for version control.
• Backup/Restore:
  • Included in DB backups (no additional overhead).
  • Point-in-time recovery possible via DB snapshots.
• Monitoring:
  • Metrics to Track:
    • key_value_store.query_time (slow queries).
    • key_value_store.write_latency (insert/update delays).
    • key_value_store.table_size (growth trends).
  • Alerts: Set up for lock contention or large value sizes.

Support

• Debugging:
  • Logs: Enable Doctrine