The Hong Kong Databricks FSI Community Day 2026 stands out as a highly unique, independent gathering happening directly within the Hong Kong Island waters. Operating away from typical convention centers, this exclusive, invitation-only event takes place entirely aboard a private boat traveling along the local ferry route. The forum serves as a dedicated working exchange for professionals operating at the intersection of complex data streams, financial markets, risk modeling, and institutional oversight.
To maintain absolute psychological and operational safety for its attendees, the organizers have stripped away traditional corporate hierarchies and product pitches in favor of open, critical peer challenges. There are no speaker names, titles, or recording devices permitted on board, ensuring that all field briefings focus strictly on executable expertise rather than corporate branding. Over thirty distinct technical proposals detail real-world financial architectures, handling everything from cross-border liquidity management and real-time streaming calculation paths to data isolation between entities in Hong Kong and Singapore. This community-driven event remains entirely independent of Databricks corporation, functioning instead as a private, expert-led ecosystem for practitioners navigating the realities of fragmented regional market structures.
Event Page:
https://vertexmacro.com/events/databricks_community_day_2026/index.html
Group Page:
https://usergroups.databricks.com/hong-kong-databricks-fsi-group/
Topic:
Tracing Lakebase from WAL Commit to Page Reconstruction: Reliability and Observability for Asia FSI
Focus:
Distributed Systems Reliability and Advanced Observability
Speaker Background:
Institutional platform engineering lead specializing in distributed Postgres, operating-system observability, network reliability, and regulated financial infrastructure. The speaker designs resilient data services for Asian trading, risk, and operational teams, translating low-level storage, packet, and recovery behavior into measurable controls for production systems.
Description:
Asian financial institutions require databases that remain explainable under stress, not merely fast during a benchmark. A trading application may commit an order, update a limit, or persist an investigation state while infrastructure components span availability zones, cloud object storage, stateless compute, security boundaries, and multiple operational teams. When latency rises, engineers must determine whether the delay originated in application code, Postgres execution, lock contention, WAL acknowledgement, network routing, pageserver reconstruction, cache behavior, object storage, or downstream analytics.
This session conducts a reliability-oriented teardown of the Lakebase architecture. Traditional Postgres places compute, WAL, and data files near one machine. Lakebase separates stateless Postgres compute from a distributed storage layer composed of safekeepers, pageservers, and cloud object storage. Safekeepers durably record WAL before a committed transaction is acknowledged, while pageservers support reads and persist durable state into managed object storage. This separation enables capabilities such as autoscaling, scale-to-zero, read replicas, copy-on-write branches, and fast failover, but it also changes the signals engineers must observe.
The walkthrough begins at INSERT or UPDATE. The compute node generates WAL and sends it to safekeepers. Reliability analysis follows commit latency, LSN progress, quorum acknowledgement, connection state, retransmission, and failure boundaries. It then traces how pageservers consume WAL and make database pages available to compute. When compute experiences a cache miss, the read path may require a page corresponding to a particular LSN. The session explains the conceptual reconstruction path without treating undocumented implementation details, algorithms, media types, or internal protocols as contractual product behavior.
Observability is organized into four layers. Application telemetry records request identity, strategy or service, transaction boundaries, retries, timeout class, and business impact. Postgres telemetry records plans, session history, wait events, normalized statement statistics, DDL changes, database counters, and logs. Host and runtime telemetry covers CPU, memory, connection pressure, cache effectiveness, deadlocks, row operations, and working-set behavior. Network telemetry measures DNS, TLS, connection establishment, packet loss, retransmission, RTT, route changes, and cross-zone dependencies.
Lakebase observability system tables can expose query plans, active session history, wait events, schema changes, database and compute health, and Postgres logs in the system.lakebase schema. Built-in metrics and activity views complement this telemetry. The session demonstrates how to correlate an application trace with a Postgres session, plan, wait event, and infrastructure interval, then attach the finding to a service-level objective and incident timeline. Because current telemetry retention and preview status can limit historical coverage, regulated institutions should export required evidence into approved long-term monitoring and retention systems.
The advanced network section uses controlled packet metadata rather than unrestricted payload capture. Teams build allowlisted flows, private endpoints, identity-aware access, egress restrictions, firewall policy, and zero-trust segmentation. eBPF or equivalent operating-system instrumentation can observe socket latency, retransmission, connection churn, scheduler delay, and system calls where organizational policy and platform support permit it. Payload inspection is minimized, tokenized, or prohibited when it could expose credentials, orders, customer information, or regulated communications.
A realistic Asia incident begins during simultaneous regional session opens. Connection counts rise, one application deployment introduces a poor query plan, and a route change increases network RTT. The database remains available but p99 transaction latency breaches its objective. The team correlates app spans, session history, waits, plan changes, CPU pressure, cache behavior, and network evidence. It distinguishes storage durability from compute availability, scales the affected compute, rolls back the application, verifies LSN progress, and confirms that committed transactions remain intact.
Chaos engineering validates recovery rather than manufacturing uncontrolled failure. Experiments run first on branches or isolated environments using synthetic or masked workloads. Scenarios include compute restart, availability-zone impairment, connection exhaustion, packet loss, dependency timeout, stale DNS, object-store throttling, and delayed downstream consumers. Guardrails define blast radius, abort conditions, trading-calendar exclusions, customer-impact limits, independent monitoring, and named recovery owners.
For multi-cluster financial environments, the blueprint establishes golden signals, trace propagation, standardized labels, synchronized clocks, runbook automation, and regional ownership. Recovery tests measure RTO, RPO, transaction ambiguity, reconnection behavior, backlog replay, and evidence completeness. Instant branching supports production-like diagnostics without copying an entire database, but access, masking, retention, and test-data controls remain mandatory.
The core lesson is that storage separation improves resilience only when teams understand the new failure domains. Institutional reliability comes from correlating business transactions with database, storage, compute, and network evidence, then repeatedly proving that automatic recovery preserves correctness as well as availability.
Audience Takeaways:
Participants receive a low-level Lakebase reliability model, observability taxonomy, trace-correlation method, zero-trust network pattern, and controlled chaos-engineering plan. They will learn how to diagnose commit and read-path latency, distinguish compute failure from durable-storage risk, validate recovery across Asian regions, and preserve audit evidence without exposing sensitive trading or customer data.
Top comments (0)