Backend Developer

• I was the backend developer who turned a senior developer's promotions architecture into working code, so a promo set up once at the POS runs the same way online across 104 store channels. I shipped 5 of its 6 work areas to staging. I also shaped the design in one important place: I identified the sync-delay risk and pushed for the end-time safety buffer that addresses it.
• I took the initiative to build the frontend client side of the system to fill the manpower gap of the team.

• My major architectural contribution is identifying that the gap between the POS and the website could let customers buy at prices that had already expired, and I pushed the fix that closed it.
• The sync runs about every 40 minutes. Picture a promo that ends at 6:00 PM in store.
• The website only learns about it at the next sync, so for that window it keeps selling at a discount the store no longer honors. The reverse also happens: a new in-store promo is not yet visible online.
• I wrote this problem into the architecture doc and argued for an end-time safety buffer. The website treats every promo as ending a configurable few minutes before its Redbox end date:
• effective_end = end_date - safety_buffer

• The Redbox payload format was not available, so I designed a working contract myself and built against it instead of waiting.
• The contract (sample-payload.json) describes one promo setup per promotion: its Redbox ID, dates, rules, catalogue, discount type and value, and the list of stores that carry it.
• Redbox sends each promo once, and the website distributes it to the right stores. That keeps the payload small compared with one message per store.
• The architecture puts all Redbox-specific translation in a mapping layer inside the sync service, and I implemented it that way. The checkout engine only reads our own database and never sees Redbox. When the real schema arrives, or when the ERP replaces Redbox, the mapping changes and the engine stays as it is.

The business can now run a store promo online without re-entering it by hand, and measure it once it goes live.

• One setup, every channel: a promo configured once at the POS reaches whichever of the 104 stores Redbox lists.
• Online matches in-store: the same rules decide eligibility and discount, and the buffer keeps the site from selling past a promo's end.
• Measurable from day one: each order discount stores the promotion rule that produced it, so usage and revenue per promo can be totaled in production.
• Ready for the ERP move: the engine does not depend on Redbox, so only the mapping has to change. Room to grow: 3 of the 27 schemes are live in staging. The engine is scheme-aware, so bracketing discounts, coupons and the other free-item variants each add their own logic on the same foundation.

The riskiest bug can live between two systems. No single component was wrong in the sync-delay case; the gap between them was. Naming that early changed the design.

• A missing spec is not a reason to stop. Writing my own contract let me build and test while the real schema was still pending.
• Keep the source at the edge. Isolating Redbox in a mapping layer means the harder part, the rules, survives a system change.