Converting Google Apps Script attendance system to Firebase + Laravel: Best approach for real-time clock-in sync?

Context

Junior full stack developer here, I'm migrating a Google Apps Script attendance management system to a hybrid architecture:

Frontend: Firebase Hosting (HTML/CSS/JS clock interface) Backend: Laravel 10 + PostgreSQL (on-premise server for dashboard/reports)

Current Architecture:

Employees clock in/out via web interface → Calls Google Apps Script → Writes to Google Sheets Admin dashboard displays data from same Google Sheets

Target Architecture:

Employees clock in/out via Firebase app → Calls Laravel API → Writes to PostgreSQL Admin dashboard (Laravel Blade) displays data from PostgreSQL

Problem

I need to decide how to handle the communication between the Firebase frontend and Laravel backend for clock-in/out actions.

Option A: Direct API Call (Current Plan)

///javascript // Firebase clock.js fetch('https://api.mycompany.com/api/public/clock', { method: 'POST', headers: { 'X-API-Key': CONFIG.API_KEY, 'Content-Type': 'application/json' }, body: JSON.stringify({ id, action, lat, long }) })

Option B: Use Firebase Realtime Database as Queue

///javascript // Firebase writes to Realtime DB firebase.database().ref('clock_actions').push({ id, action, timestamp }) // Laravel listens via webhook or polling

Questions

Security: Is exposing a public Laravel API endpoint with API key authentication sufficient? Or should I use OAuth/JWT?

Network reliability: If the on-premise server is temporarily unreachable, Option A fails immediately. Would Option B (Firebase as intermediary) provide better resilience?

Rate limiting: With ~200 employees clocking in during rush hour (8-9 AM), which approach handles concurrent requests better?

Environment

Laravel 10, PHP 8.2 PostgreSQL 15 Nginx reverse proxy Firebase Hosting (no Firebase Auth currently)

Is Option A sufficient for this scale, or should I use different language reliability/easy development?