Optimizing for the Divine: A Technical Deep Dive into Virtual Candle Architecture

When faced with the challenge of building a virtual candle website for Padre Marcelo Rossi, many developers might default to a standard CRUD approach: PostgreSQL, a cron job for expiration, and deployment to Vercel. This thinking, while practical for small-scale applications, reveals a fundamental misunderstanding of the problem's true scale and requirements.

The Scale Challenge

Brazil has 203 million inhabitants. If just 1% of these individuals light a virtual candle each week, we're looking at approximately 2 million concurrent candles at any given moment. Each candle contains significant data: name, date of birth, phone, address, neighborhood, city, state, country, email, and prayer intention. A naive approach would store this as UTF-8 strings, leading to substantial inefficiency.

The typical developer might store this information with 180+ bytes per record. However, with PostgreSQL overhead (tuple headers, MVCC, alignment, indexes), we easily reach 400+ bytes per record when the same data could be compressed to under 100 bytes. This inefficiency isn't just a technical concern—it represents a failure to serve the faithful optimally.

The Optimized Architecture

After extensive analysis, I've developed an architecture that prioritizes memory efficiency, performance, and theological appropriateness.

Core Technology Stack

Language Choice: Rust with #![no_std] in hot paths provides zero runtime overhead and no garbage collection. While C was considered, the sanctity of memory safety takes precedence when presenting the system to the Divine.

Binary Schema Design

The schema represents a careful optimization of each field:

• Date of Birth: u16 representing days since 1900-01-01 (covers until 2079). 2 bytes.
• Phone: Brazil has exactly 11 digits (DDD + 9 + 8). Stored as integer, rounded to 5 bytes aligned. The extra bits are reserved for flags like "has WhatsApp" and future features.
• City: IBGE catalogs 5,570 Brazilian municipalities, fitting in 13 bits. Using u16 with direct IBGE code allows joins with external databases without storing strings. 2 bytes.
• State + Country: 27 Brazilian states (5 bits) and ISO 3166-1 numeric codes (~250, 8 bits) share a u16. 2 bytes total.
• Address + Neighborhood: Compressed with Zstd dictionary trained on Brazilian postal codes. Common terms like "Rua", "Avenida", "Jardim" compress to 1-byte tokens. Average: ~26 bytes.
• Name + Email: Similar Zstd compression with Brazilian names/providers dictionary. ~25 bytes combined.
• Prayer Intention: The most challenging field. Analysis shows 70% fit in 40 characters. Compressed to ~25 bytes inline, with longer prayers handled via overflow pool.

The complete slot is exactly 128 bytes (2 cache lines) with an 8-byte header (timestamp + flags) and ~88 bytes of payload + 32 bytes reserved for future sacramental digital services.

Storage Implementation

Instead of traditional databases, we use a ring buffer memory-mapped to disk, append-only with a fixed 7-day TTL. The problem structure naturally maps to a ring buffer—forcing a relational database here would be architectural violence.

Overflow Handling

Handling outliers like "Maria Eduarda Gonçalves de Albuquerque Cavalcanti" living on "Rua Desembargador Antônio Carlos Figueiredo Jobim" with an 800-character prayer requires special consideration. We cannot refuse service based on data length, nor can we inflate the standard slot size for uncommon cases.

The solution: segmented overflow pools by field. Each variable-length field has a 1-byte marker + 3-byte offset in the main slot pointing to a dedicated heap. If compressed data fits inline, it stays there. Otherwise, the marker becomes 0xFF and the value moves to the respective field's overflow pool. This maintains cache locality while accommodating outliers—<2% of fields actually use overflow.

Expiration Mechanism

No cron jobs needed. The ring buffer is partitioned into 7 daily buckets. At day start, the 7-day-old bucket is overwritten, and corresponding overflow segments are truncated in blocks. Expiration occurs in O(0) time, with candles extinguishing themselves naturally, mirroring physical reality.

Frontend Considerations

Server-side rendering with streaming ensures the candle animation works even with JavaScript disabled. The flame animation is a single 400-byte SVG with no JavaScript—faith shouldn't depend on V8.

The Unikernel Solution: SeraphOS

Benchmarking revealed Linux kernel interference as the critical bottleneck: syscalls, context switches, TLB flushes, and the CFS scheduler allocating CPU to systemd-timesyncd during prayer processing. The symbolism of running "daemons" in background while faithful pray was theologically problematic.

The solution: SeraphOS, a custom unikernel inspired by MirageOS and Unikraft but tailored to our specific needs:

• Zero background daemons: No cron, systemd, sshd—just the application in ring 0
• Single-process architecture: No userspace/kernelspace separation
• 30ms boot time directly to KVM hypervisor
• Cooperative scheduling: Modified Tokio runtime with green threads
• Custom network stack: Linux kernel bypass via DPDK-style polling
• Direct NVMe access: No traditional filesystem—ring buffer is storage
• No user accounts: The system is a black box in production

Results: p99 latency dropped from 400µs to 12µs, with throughput reaching 3.1M candles/second on a t3.micro. The new bottleneck is network bandwidth—a physical limitation, not a software failure.

Versioning and Deployment

GitHub was rejected due to Microsoft's ownership and Activision/Candy Crush associations. The choice was Fossil—a distributed version control system created by the SQLite author, distributed and self-hosted with wiki, bug tracker, and forum in a single 4MB binary.

The repository runs on dedicated hardware behind Nginx, mirrored across three machines named "Pai", "Filho", and "Espírito Santo"—technologically appropriate and theologically resonant.

Engineering Trade-offs

Critics may label this overengineering. However, overengineering adds complexity without purpose. Here, every decision addresses real constraints: finite memory, CPU costs, and the duty to serve as many faithful as possible. Computing originated from counting souls in censuses—returning to these fundamentals sometimes provides the optimal path.

Featured image: The optimized virtual candle architecture

Conclusion

This architecture demonstrates how understanding problem constraints allows for solutions that defy conventional approaches. By combining low-level optimizations with thoughtful data modeling, we can serve millions of requests efficiently while respecting the theological significance of the application.

The journey from naive CRUD to custom unikernel highlights an important principle: in systems design, as in faith, understanding the true nature of the problem leads to solutions that transcend conventional limitations.

Am 🕯️