went through this in March 2026 for a staff-ish infrastructure role on their retail platform. sharing the system design specifics because i couldn't find much detail on this anywhere before my loop.
the prompt i got: design an inventory availability service that surfaces real-time product availability across IKEA's global store network and their e-commerce platform. sounds boring on the surface but actually has a lot of depth.
where they pushed: consistency vs. availability tradeoff. store inventory can lag. how do you reconcile that in the UI? do you show 'likely in stock' vs. guaranteed? they wanted a real opinion, not a textbook recitation of CAP theorem. write throughput at store level. IKEA stores do huge transaction volumes, especially weekends. they asked how you'd handle bursts without killing your DB. caching invalidation. if a product goes out of stock, how quickly does the e-commerce site need to know? they seemed to want discussion of TTLs, event-driven invalidation, and the tradeoffs. cross-region. they have stores in ~60 countries. the question of where you run your consistency logic matters a lot.
what i noticed about the interviewers: they were not testing rote architecture knowledge. they pushed back on everything with 'why not X instead?' not to trip me up but to see if i could defend a decision under pressure. the vibe was closer to a peer design review than a gotcha quiz.
timing: the first 5 minutes they let me clarify requirements. i asked about SLAs for data freshness and the scale of concurrent users, both of which shaped my whole answer. do not skip the requirements phase.
for prep: i'd recommend being comfortable with event-driven patterns (Kafka-style), multi-region caching, and explicitly practicing 'i'm choosing X because Y tradeoff, here's what we give up.' they did not care about specific vendor names. AWS vs. GCP was totally neutral.
result: moved to the next round. posting separately on the behavioral panel.