Responsible for chat functionality in team development. Built a prototype using Vanilla JS and Firebase, prioritizing development speed and validation in the initial phase. Following verification, a fundamental redesign focused on type safety and data integrity was decided to ensure long-term scalability and operational stability.
Based on the existing implementation, the necessity for a redesign was identified from the following perspectives:
The decision was made to redesign and reimplement the chat functionality as a standalone module, prioritizing the resolution of state consistency across multiple clients.
Treat DB as the Single Source of Truth
Why: Client-driven state management can lead to inconsistencies.
How: Restrict all writes to RPCs (Database Functions). Treat client-side state solely as a "projection" of the database.
Consolidate Authorization and Data Operations within the DB
Why: Authorization checks at the application layer can cause TOCTOU (Time-of-check to time-of-use) issues.
How: Use RPCs with INSERT ... SELECT to execute permission checks and writes in a single transaction. Implement Row Level Security (RLS) as the final line of defense.
WAL-based Real-time Synchronization
Why: Notification-based systems (WebSocket events) decouple "storage" from "delivery," leading to potential inconsistencies.
How: Utilize Supabase Realtime's postgres_changes. Broadcast only "committed facts" triggered by the database Write-Ahead Log (WAL).
End-to-End Type Safety
Why: To ensure safety during schema changes and maintain high refactoring resilience.
How: Adopt TypeScript. Generate types via Supabase CLI to share a unified schema across Client, Server, and Database.
Separation of Responsibilities:
This architecture ensures a clear separation between the processing path and the synchronization path.
During the redesign process, the following inconsistency was encountered:
Case: Authorization Inconsistency Across Multiple Tabs
1 User leaves an event in Tab A.
2 Immediately after, the user posts a message in Tab B.
3 While the post should be rejected, the operation succeeds.
Root Cause:
This issue stemmed from a sequential process where:
Approach: Full Closure within the DB Layer
Results:
Supplementary Strategy: Optimistic Updates and Rollbacks
The redesign yielded the following improvements:
In this case, rather than a simple replacement of existing features, a "reconstruction focused on data integrity" was performed. Specifically, a chat system that remains robust in multi-client environments was realized through:
Through this redesign, the critical importance of determining at the architectural level exactly where integrity should be enforced was learned.