# Abhishek Thulasi ## Founding Systems & Product Engineer > I architect and build systems, treating operational expense and user retention as the core metrics. ### Operating Principles - I choose technology based on the stakes. - If the goal is raw performance, I optimize at the systems level. - If the goal is rapid delivery, I leverage abstractions. - If the goal is "Fast, Cheap, and Perfect"... I help stakeholders choose the two that matter now. --- ## Engineering Portfolio & Case Studies ### Cross-Platform Multiplayer Ecosystem (2026) **Core Ecosystem Foundation** - **Context:** Corporate - **Classification:** Systems Tier - **Core Stack:** Distributed Architecture, Go & Rust, AWS - **Resources:** [View Architecture Logs →](https://abhishekthulasi.com/architecture/multiplayer-ecosystem-infrastructure) #### Implementation Scope Designed the foundational architecture for a cross-platform multiplayer ecosystem, balancing long-term maintainability with rapid development cycles. I architected a cross-platform game launcher utilizing Flutter and Rust-based binary patching, while simultaneously defining engineering standards for the Unity client—introducing .asmdef compiler fences, dependency injection, and strict garbage collection optimizations. Beyond core architecture, I pitched an immersive, "scrollytelling"-driven web portal leveraging Lenis scroll and mentored junior developers to unblock parallel workflows. The backend relies on a unified monorepo that strictly separates stateless logic from stateful persistent coordination, orchestrating observability via OpenTelemetry for distributed tracing. #### Architecture Decisions & Engineering Logs ##### ADR 001: In-Memory Data Store Selection (Jan 2026) — Status: Accepted - **Tags:** Valkey, AWS ElastiCache, Cost ROI - **Context:** The architecture requires an in-memory store for caching and ephemeral session management. As a Day-0 project, capital efficiency and deployment speed were primary constraints. Benchmarking of external data stores (e.g., Memcached, Dragonfly) was bypassed to avoid introducing networking overhead outside our primary AWS VPC. - **Decision:** `Intercepted the default Redis integration and provisioned AWS ElastiCache (Valkey) as the foundational in-memory store.` - **Rationale:** - Ecosystem Anchoring: Restricting the selection to native AWS managed services eliminates the operational overhead of VPC peering and third-party billing. - Capital Efficiency: AWS ElastiCache for Valkey operates at a 33% lower cost compared to equivalent Redis nodes, optimizing initial startup runway. - Risk Mitigation: Valkey acts as a 1:1 API drop-in replacement for Redis. If Valkey suffers from maintenance degradation, the connection string can be migrated back to ElastiCache Redis with minimal code changes. ##### ADR 002: Game Launcher Tech Stack (Jan 2026) — Status: Accepted - **Tags:** Rust FFI, Flutter, Cross-Platform - **Context:** The platform requires a standalone game launcher handling authentication handoffs, social features, and binary delta patching. Extensive ecosystem features for Android necessitated a robust mobile foundation. - **Decision:** `Build a Flutter Frontend connected to a Rust Core via flutter_rust_bridge (FFI).` - **Rationale:** - Resource Optimization: Consolidating UI development into Flutter reduces the overhead of staffing platform-specific engineering teams. - Discarded Alternatives: Electron was rejected due to its bundled Chromium footprint and lack of mobile support. Tauri was also passed over, as its Android ecosystem was deemed too immature for our mobile roadmap while introducing UI inconsistencies via its webview dependency. - Native Extensibility: Flutter's method channels provide an escape hatch for platform-level implementations where cross-platform abstractions fail. - Backend Integration: Rust guarantees memory safety, which Flutter natively supports via efficient FFI integration. - Platform Isolation: Both tools allow conditional compilation. Heavy Rust binaries (BLAKE3, mmap) are dropped for lean Android builds while preserving bare-metal disk I/O for desktop users. ##### ADR 003: Telemetry Serialization & API Bifurcation (Feb 2026) — Status: Accepted - **Tags:** gRPC/Protobuf, Bandwidth Optimization, GC Mitigation - **Context:** The core gameplay loop demands high-frequency data synchronization. The Unity client, especially on constrained hardware, is susceptible to frame drops from Garbage Collection (GC) spikes during heavy serialization workloads. CPU allocation overhead and AWS egress bandwidth must be minimized. - **Decision:** `Implement gRPC/Protobuf for all high-frequency game data and WebSockets. Utilize hash-gated fetching for large payloads, and restrict JSON/REST to initial authentication.` - **Rationale:** - GC Mitigation: JSON was rejected for game-state transfer. Parsing large JSON strings in C# creates heap allocations, causing GC stutter. Protobuf's binary serialization reduces client-side processing overhead. - Egress Cost Optimization: Protobuf's binary format reduces payload size compared to verbose JSON, lowering AWS data transfer out (DTO) costs at scale. - Hash-Gated Fetching: To mitigate bandwidth waste, large profile payloads are prefaced with a lightweight hash comparison. The Unity client only fetches and deserializes the full binary payload if the server-side hash invalidates the local cache. - Architectural Exception: JSON/REST is retained for identity management. Authentication requests are infrequent, making the GC impact negligible and simplifying the web portal's tooling. This allows us to utilize standard web tooling for our web portal without forcing complex gRPC-web proxies into the browser layer. ##### ADR 004: Web Portal Edge Architecture (Feb 2026) — Status: Accepted - **Tags:** Svelte, Cloudflare Pages, Performance - **Context:** The web portal serves as the primary user-facing application, bridging interactive content with secure identity management. The existing infrastructure (Wix) limited our ability to implement fluid UI experiences, obscured granular SEO control, and incurred recurring costs. - **Decision:** `Build a custom Svelte application deployed via Cloudflare Pages.` - **Rationale:** - Cost & Control Optimization: Migrating off a managed builder grants granular DOM control for SEO. Cloudflare Pages leverages edge networks to effectively reduce portal OpEx to zero. - Performance: Svelte provides granular state reactivity, critical for optimizing render times so complex scroll and animation libraries (Lenis) perform without framework-induced stuttering. - Discarded Alternatives: React was rejected due to Virtual DOM overhead and unnecessary architectural complexity for our UI needs which makes it easy to write poorly optimized code without strict enforcement standards. SolidJS offered superior raw performance but its developer experience was less conducive to rapid iteration. - Hiring Risk Mitigation: Acknowledged the smaller talent pool for Svelte by establishing a strict pre-production threshold. If staffing requirements were not met 3 months prior to project kickoff, the architecture had a pre-approved fallback to revert to React, absorbing the framework's overhead to protect the delivery timeline. - Edge Computing Integration: Svelte server actions compile to Cloudflare Workers, allowing secure proxying to the AWS backend and native Web Crypto API integration with zero cold-starts. ##### ADR 005: Asynchronous Spatial Streaming (Feb 2026) — Status: Architectural Blueprint - **Tags:** Unity Addressables, Memory Limits, VR Target - **Context:** During R&D, a strict 8GB shared memory limit was identified on the Meta Quest 3. Loading 1:1 scale environments as monolithic scenes would lead to Out-Of-Memory (OOM) crashes on standalone VR hardware. - **Decision:** `Architect the technical blueprint for an asynchronous Addressable Spatial Grid, shifting away from standard Unity scene loading.` - **Rationale:** - Risk Identification: Manual modeling of a cross-platform open world was determined to be a production risk without aggressive LOD and texture-stripping pipelines. - Hardware Overrides: The architecture dictates dynamically streaming asset chunks in and out of memory based on the player's active radius, appending platform-specific suffixes (e.g., baked lighting for Android, dynamic lighting for PC). - Domain Handoff: Drafted as an R&D blueprint to serve as a mandate for incoming Technical Art and Client Engineering leads, providing the framework needed to execute CI/CD automation. ##### ADR 006: Cross-Platform Compilation Fences (Mar 2026) — Status: Architectural Specification - **Tags:** Assembly Definitions, Platform Isolation, CI/CD - **Context:** Managing a single codebase for Consoles, PC, and VR introduces the risk of platform dependencies bleeding together. If high-level scripts reference opposing SDKs, the compiler fails and breaks the CI/CD pipeline. - **Decision:** `Enforce strict compiler-level isolation using Unity Assembly Definitions (.asmdef) across the project structure.` - **Rationale:** - Interface-First Architecture: Core assemblies contain only interfaces and data models (e.g., `IInteractable`). Platform-specific assemblies (e.g., `PC.asmdef`, `VR.asmdef`) implement these interfaces but are forbidden from referencing each other. - Selective Wrapping: Third-party code is sandboxed within its own .asmdef to prevent dependency pollution. Core infrastructure with a high risk of vendor lock-in (Analytics, Matchmaking) is hidden behind internal interfaces. Tightly coupled utilities (DOTween, UI frameworks) are exempt to maintain developer velocity. - Strategic Handoff: Established to protect architectural integrity from Day 1, providing the foundational ruleset required to maintain a hardware-isolated codebase. ##### ADR 007: Compute Workload Bifurcation (Apr 2026) — Status: Architectural Specification - **Tags:** AWS ECS, Fargate WebSockets, Stateless Express - **Context:** The backend needs to handle stateless HTTP traffic (Identity) and highly stateful, long-lived WebSocket connections (Matchmaking, Chat). The planned deployment on AWS App Runner was impacted by the service's scheduled deprecation. - **Decision:** `Abandoned App Runner. Bifurcated the compute layer: stateless APIs deploy via AWS ECS Express Mode, while WebSockets route to ECS Fargate.` - **Rationale:** - Vendor Deprecation: Immediate migration to the core ECS control plane ensured long-term platform stability. - Capital Efficiency: ECS Express Mode reduces infrastructure expense for stateless requests during development by sharing a single Application Load Balancer (ALB) across multiple services. - Protocol Alignment: Express Mode handles burst-scaling for HTTP authentication, while Fargate provides the granular network control required to prevent websocket drops during sustained sessions. - Scale-Out Path: Standardizing on the ECS control plane ensures a smooth migration of stateless APIs to Fargate when traffic hits production scale. --- ### Ecosystem-Wide Passwordless Authentication (2026) **Valkey-Backed Custom IDP & Biometric Auth Pipeline** - **Context:** Corporate - **Classification:** Systems Tier - **Core Stack:** Golang, PASETO, WebAuthn - **Resources:** [View Architecture Logs →](https://abhishekthulasi.com/architecture/fido2-identity-server) #### Implementation Scope Engineered a custom passwordless Identity Provider using Golang and Svelte. The onboarding flow utilizes Zepto for initial email OTP verification. Infrastructure protection includes rate limiting, email-bombing prevention, and OTP retry locking. Valkey handles this ephemeral state, providing sub-millisecond validation for the 5-minute OTP lifecycle. Upon successful validation, user profiles persist to AWS Aurora PostgreSQL, and the system prompts the user to register a device Passkey (FIDO2/WebAuthn). This ensures subsequent logins are biometric authentications, secured via PASETO session tokens. #### Architecture Decisions & Engineering Logs ##### ADR 001: Cross-Platform Authentication Handoffs (Jan 2026) — Status: Accepted - **Tags:** WebAuthn/FIDO2, VR Hardware Constraints, UX Optimization - **Context:** The ecosystem spans a desktop game launcher, a web portal, and a standalone VR client. Typing passwords via VR controllers or console interfaces presents a UX bottleneck that hinders user conversion and onboarding. - **Decision:** `Eliminated passwords in favor of FIDO2/WebAuthn. Implemented cross-device bridging and UX-driven device fingerprinting to label credentials.` - **Rationale:** - Frictionless Flow: Users register hardware once. Subsequent logins on constrained interfaces are handled via biometric prompts or cross-device QR handoffs. - Reduced Liability: The database only stores public keys, making it unusable by attackers and eliminating the compute cost of password hashing. - Device Fingerprinting: The registration flow parses the User-Agent to generate readable labels (e.g., 'Chrome on Windows') for credential managers. ##### ADR 002: Stateless Token Cryptography (Jan 2026) — Status: Accepted - **Tags:** PASETO v4 Local, Stateless Sessions, Security Standard - **Context:** The stateless API layer requires a secure session token mechanism. While JSON Web Tokens (JWTs) are standard, they introduce cryptographic liability (e.g., algorithm confusion attacks). - **Decision:** `Implemented PASETO v4 Local (Symmetric) for all session tokens.` - **Rationale:** - Secure Defaults: PASETO removes cryptographic agility from the header. The verification algorithm is hardcoded on the server, preventing downgrade attacks. - Developer Experience: Eliminates the need to validate token headers manually or configure complex JWT libraries. - Standardization: Ensures all backend microservices share a single cryptographic standard for session management. ##### ADR 003: Rate Limiting & Abuse Prevention (Feb 2026) — Status: Accepted - **Tags:** ZeptoMail API, Valkey Middleware, OOM Protection - **Context:** Passwordless onboarding relies on email OTPs. Exposing an unauthenticated endpoint invites automated abuse, email bombing, and OTP brute-forcing. - **Decision:** `Adopted Zoho's ZeptoMail for transactional delivery, secured by a Valkey-backed rate limiting and lockout mechanism.` - **Rationale:** - Provider Selection: ZeptoMail integrated frictionlessly with existing infrastructure and proved cost-effective while prohibiting marketing bulk to protect sender reputation. - OOM Protection: A strict 1MB request body limit applied at the middleware layer mitigates memory exhaustion attacks. - Dual-Vector Rate Limiting: Valkey middleware independently tracks raw client IPs and requested email addresses. The `/register-init` endpoint is strictly limited, making email-bombing cost-prohibitive. - Brute-Force Lockout: Valkey tracks failed OTP attempts. Upon reaching 5 failures, the OTP and counter are purged, locking the user out. ##### ADR 004: Ephemeral vs. Persistent State Bifurcation (Feb 2026) — Status: Accepted - **Tags:** Valkey TTLs, AWS Aurora, Vacuum Cycle Avoidance - **Context:** OTP and WebAuthn flows generate ephemeral data. Storing this in a relational database triggers vacuum cycles and increases storage costs. - **Decision:** `Route ephemeral state to Valkey (with native TTLs) and reserve AWS Aurora PostgreSQL for permanent data.` - **Rationale:** - Database Health: Prevents Postgres from accumulating dead tuples from expired sessions. - Infrastructure Efficiency: Leverages Valkey's native TTLs to garbage-collect expired sessions without background cron jobs. ##### ADR 005: Refresh Token Revocation Strategy (Mar 2026) — Status: Accepted - **Tags:** SHA-256 Hashing, Global Revocation, Theft Detection - **Context:** If a database is compromised, plain-text refresh tokens grant attackers persistent access to user accounts. - **Decision:** `Enforce SHA-256 hashing on all refresh tokens before database insertion and implement a cascading revocation mechanism.` - **Rationale:** - Data Protection: Storing only the SHA-256 hash renders compromised databases unusable for generating tokens. - Reuse Detection: Standard Refresh Token Rotation (RTR) is enforced. Presenting a previously used token indicates a compromised client or replay attack. - Cascading Revocation: Detecting reuse triggers immediate invalidation of the token family, terminating all sessions and requiring re-authentication. ##### ADR 006: Unified Distributed Observability (Apr 2026) — Status: Accepted - **Tags:** OpenTelemetry, Custom Multi-Handler, Pool-Level Tracing - **Context:** A distributed system requires unified tracing and logging to diagnose bottlenecks. Basic `stdout` statements are inadequate for production debugging. - **Decision:** `Standardized on OpenTelemetry (OTel) across the stack, utilizing a custom multi-handler logger and injecting OTel directly into the database connection pool.` - **Rationale:** - Deep Database Tracing: OpenTelemetry is wired into the Postgres connection pool via `otelpgx`, providing span-level visibility into query execution times. - Unified Logging: A custom `multiHandler` logger mirrors structured logs to `stdout` for local development and the OTel log exporter for production aggregation. - Vendor Agnosticism: The OTel standard prevents vendor lock-in, routing telemetry seamlessly to any backend via the OTel Collector. --- ### Binary Delta Patcher (2026) **Reduced Update Payloads by 98% (128MB to 1.95MB)** - **Context:** Corporate - **Classification:** Systems Tier - **Core Stack:** Rust, Memory-Mapped I/O, bsdiff Algorithm - **Resources:** [View Engineering Logs →](https://abhishekthulasi.com/architecture/binary-delta-patcher) #### Problem Distributing multi-gigabyte application updates results in high CDN bandwidth costs for bootstrapped startups. #### Solution To prove the ROI of binary diffing and secure R&D buy-in, I engineered a Rust CLI tool that reduced update payloads by 98% (128MB to 1.95MB), cutting projected AWS CDN egress costs from $11,500 to $175 per million downloads. The core engine utilizes memory-mapped I/O (`memmap2`), the `bsdiff` algorithm for delta generation, and `zstd` for compression. State integrity is strictly enforced via `blake3` hashes embedded directly into the patch headers. Beyond single files, the tool features a custom directory patching pipeline that traverses file trees to generate a unified manifest of modified, created, and deleted assets. A key finding from this R&D phase was a scaling bottleneck: `bsdiff` suffix sorting requires holding both the old and new files in memory simultaneously. Triggering OOM thresholds on large payloads proved that production implementations must pivot to sliding-window algorithms like Xdelta or HDiffPatch to maintain a flat memory footprint. #### Architecture Decisions & Engineering Logs ##### Log 01: Diffing Engine: bsdiff for MVP (Feb 2026) — Status: Implemented - **Tags:** bsdiff, Payload Reduction, OOM Trade-offs - **Context:** To secure leadership buy-in, the immediate priority was demonstrating a significant reduction in update payloads to prove the ROI of binary diffing. The objective was to find an algorithm that yields optimized patch sizes out of the box. - **Decision:** `Implemented the qbsdiff crate (Bsdiff algorithm) as the core diffing engine.` - **Rationale:** - Pros: Successfully proved the business case for CDN cost reduction. Benchmarks showed a 120 MB base updating to a 128 MB target required only a 1.95 MB patch. - Cons (The RAM Flaw): Bsdiff uses suffix sorting, requiring both the old and new files to be held in memory simultaneously. Patch creation requires RAM equal to or greater than the new file size. - Next Steps: This technical debt is documented; for production scaling, the diffing engine will be hot-swapped for xdelta3 or HDiffPatch to balance patch size with a flat memory footprint. *Metrics: AWS Egress Cost Savings (Projected at standard $0.09/GB)* | Downloads | Cost (Raw 128MB) | Cost (Patched 1.95MB) | Total Savings | | --- | --- | --- | --- | | 1,000 | $11.52 | $0.18 | $11.34 | | 10,000 | $115.20 | $1.76 | $113.44 | | 1,000,000 | $11,520.00 | $175.50 | $11,344.50 | ##### Log 02: Custom ADIR Directory Manifests (Feb 2026) — Status: Implemented - **Tags:** Custom Archive, I/O Optimization, zstd Compression - **Context:** Standard directory diffing pipelines often generate large intermediate .tar archives before comparing them, introducing disk I/O overhead and consuming excess storage. - **Decision:** `Architected a custom directory archive format (starting with magic bytes ADIR). The system walks directories to generate a manifest of specific DiffTask operations: Patch, Create, or Delete.` - **Rationale:** - Pros: Eliminated intermediate file storage overhead. During benchmarking, the engine traversed 188 files across 21 folders, calculated diffs, and streamed the payload natively through a global zstd encoder into a unified 1.95 MB archive. - Cons: Introduces a proprietary archive format requiring a specific CLI tool to unpack, limiting interoperability with standard unzipping utilities. ##### Log 03: I/O Maximization via Memory Mapping (Feb 2026) — Status: Implemented - **Tags:** memmap2, Kernel Paging, System Performance - **Context:** Processing large binary files chunk-by-chunk through standard file I/O creates bottlenecks. Minimizing system call overhead is essential to maintaining speed in the patching pipeline. - **Decision:** `Utilized the memmap2 library to map target binaries directly into virtual memory.` - **Rationale:** - Pros: Accelerates I/O reads by delegating paging to the OS kernel, efficiently feeding byte arrays to the diffing algorithm and integrity hashers. - Cons: Requires handling unsafe blocks in Rust to initialize memory maps. The system's virtual memory limits strictly dictate the maximum file size processed during the prototype phase. ##### Log 04: Integrity Verification (Feb 2026) — Status: Implemented - **Tags:** blake3, Parallel Execution, Data Integrity - **Context:** Applying a patch to an incorrect base file version corrupts the file. Ensuring state integrity is critical, but hashing large datasets can delay patching. - **Decision:** `Integrated the blake3 algorithm for high-performance hashing. The 32-byte hash output is embedded into the patch header.` - **Rationale:** - Pros: Before applying a patch, the tool verifies the local file hash matches the embedded hash. blake3 is highly parallelizable and fast, ensuring safety checks do not bottleneck I/O throughput. - Cons: Fails strictly on hash mismatch, meaning users cannot force-apply patches to modified base files. --- ### Universal Salesforce REST Framework (2025) **Dynamic Metadata-Driven Upsert Gateway** - **Context:** Corporate - **Classification:** Systems Tier - **Core Stack:** Apex, Factory Pattern, FLS Enforcement - **Resources:** [View Source](https://github.com/abhishekthulasi/salesforce-generic-rest-api) | [View Demo](https://www.linkedin.com/posts/abhishek-thulasi_salesforce-apex-salesforcedeveloper-activity-7381644575653756928-d9la) #### Problem Standard Salesforce integrations with custom logic often require hardcoding a dedicated REST endpoint for every new data object. As an enterprise scales, this creates technical debt and rigid codebases. #### Solution Engineered a dynamic data gateway capable of upserting any SObject—and inserting nested child records—in a single bulkified transaction. To ensure the core REST controller remains untouched as business requirements evolve, the system uses a custom metadata-driven Factory pattern. This architecture allows developers to inject object-specific logic via "Before" and "After" Apex interfaces. The framework natively handles dynamic JSON type-casting and enforces Field-Level Security (FLS) across all payloads. --- ### LocalSync (2025) **Cloudless P2P Device Synchronization** - **Context:** Personal - **Classification:** Systems Tier - **Core Stack:** Rust Core, Dart FFI, Flutter - **Resources:** [View Source](https://github.com/abhishekthulasi/localsync) #### Problem Cloud storage enforces recurring operational costs and introduces privacy trade-offs, while personal devices have underutilized storage capacities. #### Solution Built a prototype for a local-first sync engine designed to bypass the cloud. Driven by a Rust core with a Flutter UI, the system targeted two primary modes: a two-way active directory sync between trusted devices, and a one-way encrypted vault. Development was paused after determining the sync feature required a fundamentally different cryptographic architecture, but the prototype successfully validated the core device-to-device communication pipeline over local Wi-Fi. --- ### Raw WebSocket Architecture (2024) **Custom Hub-and-Client Concurrency** - **Context:** Personal - **Classification:** Systems Tier - **Core Stack:** Golang, TCP Persistence, SurrealDB - **Resources:** [View Backend Source](https://github.com/abhishekthulasi/chat-backend) | [View Frontend Source](https://github.com/abhishekthulasi/chat-frontend) #### Problem Modern libraries like Socket.io abstract away the complexities of TCP persistence, connection drops, and memory management. This project was built to explore the raw engineering behind stateful network connections. #### Solution Engineered a full-duplex chat system from the ground up without managed real-time wrappers. The backend is written in Golang, utilizing a custom Hub-and-Client architecture that leverages goroutines and channels to multiplex raw WebSocket streams safely across concurrent users. The frontend utilizes Svelte to manually manage the socket lifecycle and state stores, bridging real-time events with IndexedDB for local caching and SurrealDB for persistent relational storage. --- ### Enterprise Contractor App (2024) **1M+ Play Store Downloads** - **Context:** Corporate - **Classification:** Enterprise Tier - **Core Stack:** Flutter, Global State Management, CI/CD - **Resources:** [View on Play Store](https://play.google.com/store/apps/details?id=pidilite.com.udaan) #### Implementation Scope Served as a core frontend engineer for India's largest adhesive manufacturer's mobile ecosystem, supporting over 1M+ active Play Store downloads. Contributed to a highly scalable library of reusable Flutter components and managed complex global state, ensuring fault tolerance and CI/CD reliability within a fragmented, legacy-integrated production environment. --- ### OCR Automation Engine (2024) **90% Reduction in Manual Data Entry** - **Context:** Corporate - **Classification:** Enterprise Tier - **Core Stack:** Gemini API, Flutter, Salesforce #### Problem The deprecation of Salesforce's native scanning tool created a gap in the lead-generation workflow for hundreds of sales representatives. #### Solution Developed a custom replacement using Flutter, native OCR, and Google's Gemini API. The system handles complex relationship mapping directly into Salesforce in a single transaction. Shipped in under 30 days, the application resulted in a 90% reduction in manual data entry time for the sales team. --- ### Bengaluru Dreamin Quest (2024) **Managed 500+ Concurrent Attendees** - **Context:** Personal - **Classification:** Enterprise Tier - **Core Stack:** Experience Cloud, Apex, LWC #### Implementation Scope Developed a QR-based state machine and scoring engine for a 500+ attendee tech conference. Built using Salesforce Experience Cloud, LWC, and Apex, the system tracked user interactions (booth visits, peer networking) and immediately resolved those events into real-time point distributions to drive engagement. --- ### MuleDreamin App (2023) **Real-Time Sync for Hundreds of Devices** - **Context:** Personal - **Classification:** Enterprise Tier - **Core Stack:** Flutter, Firebase DB, Push Sync #### Implementation Scope Built the official Flutter mobile client for the event, backed by Firebase Realtime Database. To handle live operations, the architecture shifted away from standard polling REST endpoints to a persistent push-based model. This ensured the instant propagation of schedule changes and lecture statuses to hundreds of concurrent devices. --- ### Ad Accelerator (2025) **Heuristic DOM Mutation Observer** - **Context:** Personal - **Classification:** Tools Tier - **Core Stack:** JavaScript, Chrome Extension API, DOM Traversal - **Resources:** [View Source](https://github.com/abhishekthulasi/prime-video-ad-accelerator) #### Problem Sought to resolve the UX friction of unskippable ads while exploring DOM manipulation and browser extension APIs. #### Solution Because regulatory guidelines require ads to be distinguishable, streaming platforms render predictable UI elements—specifically an "Ad" label and a timer. Built a Chrome extension that monitors the DOM for these patterns and automatically fast-forwards the video playback rate the moment an ad is detected. --- ### Advanced LWC Combobox (2023) **High-Performance Open-Source Data Binding** - **Context:** Personal - **Classification:** Tools Tier - **Core Stack:** LWC, JavaScript, Custom Component - **Resources:** [View Source](https://github.com/abhishekthulasi/advanced-lightning-combobox) | [View Demo](https://www.linkedin.com/posts/abhishek-thulasi_salesforcedeveloper-salesforcelightning-lwc-ugcPost-7142375917053530112-zTsq) #### Problem The standard Salesforce Lightning component library limits search and multi-select data-binding capabilities, often requiring enterprise teams to build custom wrappers. #### Solution Engineered an open-source, performant LWC component that natively resolves these UI bottlenecks, providing a drop-in solution for complex data selection. ---