Skip to content

Here is your "Ticket Masala: Origins" Blueprint.

  1. The Deployment Topology (Docker)

You don't need docker-compose.yaml with 5 services. You just need one container.

CRITICAL REQUIREMENT: Since SQLite is a file, if you destroy the container, you destroy the database. You must mount a volume. Bash

The only command you need

docker run -d \ --name ticket-masala \ -v /host/data:/app/data # <--- CRITICAL: Maps DB file to outside world -p 8080:8080 \ -e ConnectionStrings__DefaultConnection="Data Source=/app/data/masala.db;Cache=Shared" \ ticket-masala:v1

  1. The "In-Process" Architecture

We will replace infrastructure components with .NET abstractions. This creates a "Logical Separation" without "Physical Separation."

"Enterprise" Component "Origins" Replacement (C#) Why it works RabbitMQ System.Threading.Channels High-perf in-memory queue. Worker Service IHostedService Runs a background thread inside the same app. Redis IMemoryCache Uses container RAM. Faster than network. PostgreSQL SQLite (WAL Mode) "Write-Ahead Logging" allows concurrent reads/writes. Elasticsearch SQLite FTS5 Full-text search engine built into SQLite.

  1. The SQLite "Performance Hack"

SQLite defaults to "Journal Mode," which locks the whole database for every write. This will kill your web app. You must enable WAL (Write-Ahead Logging) mode at startup.

In your DbContext or Startup:

// Run this ONCE when the app starts using (var command = connection.CreateCommand()) { command.CommandText = "PRAGMA journal_mode=WAL;"; // Unlocks concurrency command.ExecuteNonQuery(); }

  1. The Exit Strategy (Future Proofing)

The biggest fear with monoliths is "painting yourself into a corner." To avoid this, do not leak SQLite-isms into your core domain.

Bad: Writing raw SQL queries like SELECT json_extract(...).

Good: Using EF Core HasComputedColumnSql.

When you eventually outgrow SQLite (e.g., you hit 100GB of data or need geo-replication), you simply:

Spin up Postgres.

Change the Connection String.

Update the EF Core Provider in Program.cs.

The rest of your code (Channels, Workers, Logic) remains untouched.

Architect's Verdict

Approved. This approach dramatically reduces "DevOps Fatigue." You can focus 100% of your energy on the Logic (The Rule Compiler, The Config Engine) rather than debugging why the RabbitMQ container can't talk to the Worker container.