Laravel development for Malaga booking and rental operators

A Malaga booking system has a modest amount of data and one genuinely hard problem: two people trying to take the same room at the same moment.

That is unusual. Most applications get harder as data grows; a reservation system is difficult at any size, because correctness depends on what happens between two statements rather than on how many rows there are. Everything else about these systems - rates, channels, cleaning schedules - is ordinary work sitting on top of that one question.

Malaga availability is a race, and the database has to win it

The natural way to write a booking is also the broken one. Check whether the unit is free for those dates, then insert the reservation.

Between those two statements, a second request can run the same check and get the same answer. Under normal traffic it happens rarely enough to look like a mystery; during a promotion it happens every day. The guest-facing result is a confirmed reservation that cannot be honoured, and no amount of careful application code closes the gap.

The fix is to make the database refuse. PostgreSQL can hold an exclusion constraint that rejects any reservation whose date range overlaps an existing one for the same unit, which means the guarantee lives where concurrency is actually arbitrated. On MySQL the equivalent is a transaction that locks the unit row before checking, so the second request waits rather than proceeding on stale information. Either way the application's job becomes handling the rejection gracefully, which is a much easier thing to get right.

A check-in is a Laravel date, not a moment

This is the second recurring defect in Malaga rental systems, and it is subtler than it looks.

Stored as a timestamp, a check-in acquires a time zone, and a time zone turns the 14th into the 13th at 23:00 for somebody. Nightly rates count days. Minimum stays count days. Free-cancellation windows count days. Once the date drifts by hours, every one of those calculations is wrong by one in some cases and right in others, which is the hardest kind of bug to reproduce.

A date column holds a date. Money and dates are the decisions you cannot undo covers both halves of this, and in a booking system they arrive together on the same table.

Malaga seasonal rates belong to periods

A nightly price is rarely one number. There is a base rate, a season, perhaps an offer, perhaps a last-minute adjustment, and a minimum stay that only applies in August.

Modelled as columns on the unit, this becomes unmaintainable within a season. Modelled as dated periods with a defined precedence, it stays explainable - and crucially, the resolved price per night gets stored on the reservation rather than recalculated later. A guest holding a confirmation for one amount and an invoice for another is a trust problem, not an accounting one, and it is caused entirely by recomputing history from current rules.

A Malaga cancellation policy is a rule with dates in it

Free cancellation up to seven days before arrival, half the stay charged within seven days, nothing refunded within forty-eight hours. That is not a field on a booking. It is a policy with thresholds, and the thresholds are measured from a date in the property's own zone.

The policy that applies is the one that was in force when the booking was made, pinned to the booking at that moment. Changing next season's cancellation terms must not silently change what a guest agreed to in March, and the only arrangement that guarantees it is storing the resolved policy with the booking rather than a reference to a policy that can be edited.

Which is also what makes the refund computable without a conversation. A cancellation at a given moment falls into a band, the band gives an amount, and the amount is derived rather than decided. Where a human overrides it - a goodwill refund outside the policy - that is recorded as an override with a reason, so that the pattern of overrides is visible to whoever sets the policy.

Non-refundable rates sit alongside and need care, because they are a different product rather than a flag. A guest who booked a non-refundable rate at a discount has bought something else, and mixing the two in one rate structure with a boolean is how a refund gets issued that should not have been.

Malaga channel updates arrive late and overwrite each other

A property is sold through its own site and through three or four intermediaries, and every one of them holds a copy of the availability. The copies disagree, continuously, and the question is only how badly.

The direction that causes trouble is inbound. Two bookings for the last unit arrive from two channels within the same minute, and neither channel knew about the other. That is an overbooking and no amount of pushing inventory faster prevents it - the property either holds a buffer, accepts the exposure deliberately, or allocates inventory per channel so that each channel can only sell what it was given. All three are legitimate commercial choices and the system has to be able to express whichever one the operator picks.

Outbound, the problem is ordering. Updates sent to a channel can be processed out of sequence or dropped silently, so the application cannot assume that the last thing it sent is what the channel believes. What works is sending the absolute state for a date range rather than a delta, so that a lost message is corrected by the next one instead of leaving a permanent offset, and reconciling periodically by reading back what the channel thinks it has.

Every exchange with every channel wants to be logged, with the payload, because the conversation that follows an overbooking is about what was sent and when. A log that can answer that in a minute is worth the storage it costs several times over - and it is the only way to tell a channel that reported availability it was never given.

Commercially

Scope fixed in writing before work starts, priced per project. The Spain-level ground - certified invoicing, regional tax rules, public-sector requirements - sits on the Spain market page.

Invoiced by Codefacture Yazılım A.Ş. in Türkiye, in euros, by bank transfer, with no Turkish VAT under the export-of-services exemption.