Parks captures reservation events for bronze and needs a current-state silver table. How should load styles differ by layer?

Parks reservation traffic should land as append-only events in immutable bronze, while silver current-state reservation tables use MERGE to reflect what is true now. Bronze preserves the full event log for audit and replay; silver applies inserts and updates (and cancellations as deletes or status changes) so booking apps and park staff see present occupancy. Load style follows medallion purpose, not a single pattern for every layer.

Merging reservation changes into bronze for deduplicated state while silver appends cleansed rows for state reverses layer intent: bronze should not be a mutable upsert target, and current-state silver cannot stay correct on blind appends alone. Appending new reservation events into an immutable bronze log while silver uses overwrite for current state gets bronze right but uses the wrong silver load: overwrite rewrites the entire table instead of incrementally merging changes by reservation_id, so it cannot efficiently apply inserts, updates, and cancellations to maintain present occupancy. Appending new reservation events into an immutable bronze log while silver merges on event time for current state gets the key wrong: event time says when an event happened, not which reservation it belongs to, so merging on it does not collapse multiple events for one reservation into a single current-state row—the merge needs the reservation identifier as its key.

Exam caveat: Append-only immutable bronze + MERGE silver current state is a classic medallion pairing. Exam distractors often swap those verbs. Gold may aggregate from silver; it should not scrape screenshots.

Operational check: Append a create and a cancel event for the same reservation_id into bronze (row count increases by two). MERGE into silver and confirm current status is canceled with a single current-state row. Verify bronze still holds both events for audit replay.