When a guest at a wedding scans a QR code, takes a photo on their phone, and sees it appear on a projector screen two seconds later — it feels almost magical. But the technology behind it is straightforward once you understand the pieces. This article explains how real-time photo sharing works, using SnapCast as the example.

The Problem: Traditional Photo Sharing Is Slow

Traditional photo sharing flows look like this: someone takes a photo, attaches it to an email or uploads it to a cloud service, and someone else downloads it hours or days later. Even modern services like Google Photos or iCloud take minutes to sync across devices, and they require both parties to have an account.

For a live event, "minutes later" might as well be "never." The moment has passed, the crowd has moved on, and the photo has no context. Real-time photo sharing solves this by removing every step between "taken" and "displayed."

QR Codes: The Entry Point

The process begins with a QR code — a square image that encodes a URL. When you point your phone camera at it, the camera app decodes the URL and offers to open it in your browser. No app installation, no account creation.

The URL opens a mobile-optimized web page that runs entirely in the guest's browser. This page uses standard HTML file input APIs to access the phone's camera or photo library, depending on what the user chooses. The guest selects or captures a photo, and the page prepares it for upload.

Before uploading, the page compresses the image using the browser's Canvas API — reducing a 4MB phone photo to roughly 200–400KB without visible quality loss. This keeps uploads fast even on a crowded venue Wi-Fi network.

Real-Time Database Sync with Firestore

Once the image is compressed, it is uploaded to a cloud storage bucket. Simultaneously, a small record is written to a Firestore database — Google's real-time NoSQL document store. This record contains the image URL, a timestamp, and the event ID.

Firestore is designed for exactly this use case: it maintains persistent connections to all clients listening to a given collection, and pushes updates to those clients within milliseconds whenever a new document is written. It does not require clients to poll for updates — the server pushes changes as they happen.

The slideshow page, running on the display device at the venue, maintains a Firestore listener on the current event's photo collection. The moment a new photo record appears in Firestore, the listener fires and the slideshow page receives the image URL — typically within one to two seconds of the original upload.

The Slideshow: Rendering in the Browser

The slideshow itself runs as a standard web page, using CSS animations and the browser's image rendering engine to display photos. When a new photo URL arrives from Firestore, it is preloaded into an off-screen image element first. This means by the time the slideshow transitions to that photo, the full image is already in memory — there is no visible loading delay.

The slideshow cycles through all uploaded photos in a continuous loop, applying configurable transition animations between each image. The display device does not need any special software — any modern browser works, which means the same laptop you use for presentations can run the slideshow.

Remote Control Without an App

SnapCast's remote control also runs in the browser. The event organizer opens a control URL on their phone, and that page maintains its own Firestore connection to the same event. When the organizer taps "pause" or "next," the command is written to Firestore, and the slideshow page receives and executes it within a second.

This is the same pattern used by collaborative tools like Google Docs: multiple clients share state through a central database, and each client reacts to changes in real time.

Privacy: What Happens to the Photos

Photos uploaded to SnapCast are stored in the event's private cloud storage bucket. They are accessible only to people with the event URL — there is no public index, no search engine crawling, and no sharing to third-party services.

After the event, the organizer controls what happens to the photos: download the full gallery, share a view-only link with guests, or delete everything. SnapCast does not use uploaded photos for training, advertising, or any purpose other than displaying them in the event slideshow.

Why It Feels Instant

The two-to-three second latency from "photo taken" to "photo on screen" comes from three overlapping steps: compression in the browser (~0.3s), upload to cloud storage (~0.5–1s depending on connection speed), and Firestore propagation to the slideshow (~0.2–0.5s). These steps happen concurrently where possible, keeping the total round trip under three seconds on a typical venue Wi-Fi connection.

That latency is short enough that the person who took the photo is still looking at the screen when their image appears — which is what creates the "wow" moment that makes live photo walls so engaging at events.

Khi một khách mời tại đám cưới quét mã QR, chụp ảnh trên điện thoại và thấy nó xuất hiện trên màn hình máy chiếu hai giây sau — cảm giác như phép thuật. Nhưng công nghệ đằng sau nó rất dễ hiểu khi bạn hiểu các thành phần. Bài viết này giải thích cách chia sẻ ảnh thời gian thực hoạt động, dùng SnapCast làm ví dụ.

Vấn đề: Chia sẻ ảnh truyền thống quá chậm

Quy trình chia sẻ ảnh truyền thống trông như thế này: ai đó chụp ảnh, đính kèm vào email hoặc tải lên dịch vụ đám mây, và người khác tải xuống vài giờ hoặc ngày sau. Ngay cả các dịch vụ hiện đại như Google Photos hay iCloud cũng mất vài phút để đồng bộ, và chúng yêu cầu cả hai bên có tài khoản.

Đối với sự kiện trực tiếp, "vài phút sau" gần như đồng nghĩa với "không bao giờ." Khoảnh khắc đã qua, đám đông đã chuyển sang chỗ khác, và ảnh không còn ngữ cảnh. Chia sẻ ảnh thời gian thực giải quyết điều này bằng cách loại bỏ mọi bước giữa "đã chụp" và "đã hiển thị."

Mã QR: Điểm vào

Quy trình bắt đầu với mã QR — một hình ảnh vuông mã hóa một URL. Khi bạn hướng camera điện thoại vào nó, ứng dụng camera giải mã URL và đề nghị mở trong trình duyệt. Không cài ứng dụng, không tạo tài khoản.

URL mở trang web tối ưu cho mobile chạy hoàn toàn trong trình duyệt của khách. Trang này dùng API file input HTML chuẩn để truy cập camera hoặc thư viện ảnh của điện thoại, tùy theo lựa chọn của người dùng. Khách chọn hoặc chụp ảnh, và trang chuẩn bị cho việc upload.

Trước khi upload, trang nén ảnh bằng Canvas API của trình duyệt — giảm ảnh điện thoại 4MB xuống còn khoảng 200–400KB mà không mất chất lượng nhìn thấy. Điều này giữ tốc độ upload nhanh ngay cả trên mạng Wi-Fi địa điểm đông đúc.

Đồng bộ cơ sở dữ liệu thời gian thực với Firestore

Khi ảnh được nén, nó được tải lên bucket lưu trữ đám mây. Đồng thời, một bản ghi nhỏ được ghi vào cơ sở dữ liệu Firestore — kho tài liệu NoSQL thời gian thực của Google. Bản ghi này chứa URL ảnh, timestamp và ID sự kiện.

Firestore được thiết kế chính xác cho trường hợp sử dụng này: nó duy trì kết nối liên tục với tất cả client đang lắng nghe một collection nhất định, và đẩy cập nhật đến các client đó trong vài mili giây mỗi khi có tài liệu mới được ghi. Nó không yêu cầu client poll để cập nhật — server đẩy thay đổi khi chúng xảy ra.

Trang slideshow, chạy trên thiết bị hiển thị tại địa điểm, duy trì một Firestore listener trên collection ảnh của sự kiện hiện tại. Ngay khi bản ghi ảnh mới xuất hiện trong Firestore, listener kích hoạt và trang slideshow nhận URL ảnh — thường trong vòng một đến hai giây kể từ khi upload ban đầu.

Slideshow: Render trong trình duyệt

Slideshow chạy như trang web chuẩn, dùng CSS animation và engine render ảnh của trình duyệt để hiển thị ảnh. Khi URL ảnh mới đến từ Firestore, nó được preload vào một phần tử ảnh ẩn trước. Điều này có nghĩa là khi slideshow chuyển sang ảnh đó, hình ảnh đầy đủ đã có trong bộ nhớ — không có độ trễ tải nhìn thấy.

Slideshow chạy vòng qua tất cả ảnh đã tải lên liên tục, áp dụng animation chuyển tiếp có thể cấu hình giữa mỗi ảnh. Thiết bị hiển thị không cần phần mềm đặc biệt — bất kỳ trình duyệt hiện đại nào cũng hoạt động, nghĩa là laptop bạn dùng cho thuyết trình có thể chạy slideshow.

Điều khiển từ xa không cần ứng dụng

Điều khiển từ xa của SnapCast cũng chạy trên trình duyệt. Người tổ chức sự kiện mở URL điều khiển trên điện thoại, và trang đó duy trì kết nối Firestore riêng của nó với cùng sự kiện. Khi người tổ chức nhấn "tạm dừng" hoặc "tiếp theo," lệnh được ghi vào Firestore, và trang slideshow nhận và thực thi nó trong vòng một giây.

Đây là pattern tương tự được dùng bởi các công cụ cộng tác như Google Docs: nhiều client chia sẻ trạng thái qua cơ sở dữ liệu trung tâm, và mỗi client phản ứng với thay đổi theo thời gian thực.

Quyền riêng tư: Điều gì xảy ra với ảnh

Ảnh tải lên SnapCast được lưu trữ trong bucket lưu trữ đám mây riêng của sự kiện. Chúng chỉ có thể truy cập bởi người có URL sự kiện — không có chỉ mục công khai, không có công cụ tìm kiếm thu thập, và không chia sẻ với dịch vụ bên thứ ba.

Sau sự kiện, người tổ chức kiểm soát những gì xảy ra với ảnh: tải xuống toàn bộ thư viện, chia sẻ link chỉ xem với khách, hoặc xóa tất cả. SnapCast không dùng ảnh đã tải lên cho training, quảng cáo, hay bất kỳ mục đích nào khác ngoài việc hiển thị trong slideshow sự kiện.

Tại sao nó cảm thấy tức thì

Độ trễ hai đến ba giây từ "đã chụp ảnh" đến "ảnh trên màn hình" đến từ ba bước chồng chéo: nén trong trình duyệt (~0.3 giây), tải lên lưu trữ đám mây (~0.5–1 giây tùy tốc độ kết nối), và Firestore truyền đến slideshow (~0.2–0.5 giây). Các bước này xảy ra đồng thời khi có thể, giữ tổng thời gian dưới ba giây trên kết nối Wi-Fi địa điểm điển hình.

Độ trễ đó đủ ngắn để người chụp ảnh vẫn còn nhìn vào màn hình khi ảnh của họ xuất hiện — đó chính là thứ tạo ra khoảnh khắc "wow" làm cho bức tường ảnh trực tiếp hấp dẫn đến vậy tại các sự kiện.