Homestay

Implementationserver/internal is organised into auth, user, homestay, room, order and payment packages, each with model, repository, service and handler boundaries. The Gin router only composes dependencies and routes.

ValueThe deployment stays simple while booking, inventory and payment rules remain in explicit boundaries that can later be replaced or split without starting from an unstructured CRUD service.

ImplementationAmounts use int64 cents, and orders snapshot property, room and nightly prices. Redis stores only versioned room calendars, fails open to MySQL and never becomes the authority for settlement.

ValueThis avoids floating-point money errors and cache-write failures changing inventory, while payment amount checks can compare against persisted order data.

Implementationroom_inventory_daily stores total_stock, locked_stock, sold_stock, daily_price and closed for each room type and date. Checkout is exclusive, previews are capped at 93 days and bookings at 30 nights.

ValueVariable prices, closed dates and multi-night reservations can be validated with one server-side model rather than a collection of client-side assumptions.

Implementationorders has a composite unique constraint on user_id and idempotency_key. The service looks up an existing order inside the transaction and, after a concurrent unique-key race, reads and returns the order that won.

ValueNetwork retries, button double-clicks and client timeouts are much less likely to create duplicate orders because the guarantee is shared by application logic and the database.

ImplementationCreate, cancel and payment confirmation lock inventory rows in ascending date order with SELECT ... FOR UPDATE, check available stock, move locked_stock / sold_stock and verify expected RowsAffected.

ValueConcurrent reservations for the same room type serialize the critical inventory decision, while a fixed lock order reduces deadlock risk across multi-night bookings.

ImplementationCalendar keys include roomTypeID, version, start and end dates. Inventory mutations increment the Redis version; old ranges naturally become unreachable, and cache failures do not block the main transaction.

ValueOrder creation, cancellation and payment confirmation can invalidate every overlapping range without enumerating and deleting every date-range key.

ImplementationPayment Service uses a WechatGateway abstraction for production payment creation and notification verification. Local confirmation still validates order amount, merchant identity, AppID and trade status before changing inventory.

ValueThe third-party SDK does not directly mutate business stock, and duplicate callbacks, amount mismatches and expired orders have explicit local decisions.

ImplementationEmbedded SQL migrations record versions in schema_migrations and run as a separate production role. API and worker are deployed independently, keeping expiration scans out of HTTP request handling.

ValueSchema changes are decoupled from application startup, and background expiry has its own runtime and scaling boundary.