--- title: "Desèñá un fila di kapasidat multidimensional" date: 2020-12-02 language: pap topics: ["data", "ecommerce", "lemmid-store", "payments", "server", "work"] source_url: https://willem.com/pap/2020-12-02_desena-un-fila-di-kapasidat-multidimensional/ --- # Desèñá un fila di kapasidat multidimensional *Maneha kapasidat di kushina, delivery i pickup* > E luna aki mi tabatin ku krea dimenshon adishonal pa un mekanismo di fila di kapasidat. E app pa pidi kuminda ku mi a krea mester por limitá kapasidat basá riba e kantidat di orden, e kontenido di orden individual i e tipo di despachu (takeaway/delivery). Lesa hunto pa wak kon mi a usa un Lambda Architecture pa hasi esaki. ## Limitá kapasidat Aunke talbes bo no ta realisá esaki, un di e funshonnan mas poderoso di e app_pa_pidi_kuminda_ku_mi_a_krea (https://willem.com/blog/lemmid-store/) ta di bèrdat e posibilidat di limitá e kantidat di orden. Esaki ta soná kontra-intuitivo, pero dor di limitá e kantidat di orden ku por wòrdu hasí, mi klientenan (e restorantnan i dònonan di tenda ku ta usa mi app) por asegurá ku ordenan ta wòrdu prepará i entregá na un bon manera. ## Kompleksidat di tres pizza Supon ku bo ke pidi tres pizza. E app di kuminda e ora ei mester sa: - Bo ke **bai buska nan** òf ke **nan wòrdu entregá**? - **Ki ora?** Ki ora nan mester drenta e horno? - Tin **spasio sufisiente** pa *tres* pizza **den e horno** *na e ora ei*? - Si bo a skohe pickup: **nos por risibí bo sigur** na e ora ei? - Si bo a skohe delivery: **tin un hende di delivery disponibel** pa trese bo pizza? - **Tur kos ta OK?** E ora ei **por fabor paga** miéntras nos **tene bo pizza programá** den e horno i den delivery òf pickup. No a paga? Bo a kambia di opinion? E ora ei nos "deshasi" tur programashon i warda pa un otro hende pidi pizza! ![Kome pizza durante desaroyo ta kon bo "biba e algoritmo"](https://willem.com/global/images/e9229d524bd1.webp) ## Tres dimenshon di kapasidat Spesial rònt di "ora di diner" tin risko ku masha hopi hende ta pidi kuminda na mes tempu. Aunke e app por maneha e trafiko ekstra danki na su arkitektura_hopi_eskalabel (https://willem.com/en/2020-05-11_scalable-application-design-without-magic/), restrikshon físiko ta keda, manera: - **kapasidat di kushina**: e kantidat di plato ku bo por prepará na mes tempu - **kapasidat di pickup**: e kantidat di hende ku bo por risibí sigur na mes tempu, ku respekto na e restrikshonnan di COVID-19 - **kapasidat di delivery**: e kantidat di orden ku bo por entregá, tene kuenta ku trafiko, distansia i rutu ![Tres restrikshon di kapasidat: kushina / delivery / pickup](https://willem.com/global/images/db564dd30d9f.webp) ### Diferente ma interdependente E tres tipo di restrikshon aki ta interdependente. Por ehèmpel, ta posibel ku un orden grandi di pickup ta okupá henter e kapasidat di kushina, ku ta resultá den indisponibilidat pa delivery tambe. Ordenan mas chikí por wòrdu aseptá ainda pa yena kapasidat di kushina, miéntras ku por no tin kapasidat sufisiente mas pa orden grandi. Esaki ta nifiká ku bo mester un mekanismo ku ta wak *tur* e métrika huntu pa determiná e disponibilidat pa orden nobo, inkluso e kontenido di un orden ku ainda no a wòrdu pone (por ehèmpel kiko ta den bo karo di kompra). ### Diferensia den granularidat di periodo Ta komun pa definí un restrikshon físiko ku un periodo di tempu, por ehèmpel *"e kushina por produsí 10 plato pa 15 minüt"*. E ta bira un reto ora bo definí otro restrikshon físiko ku periodo di tempu di diferente largura. Miéntras e kushina por wòrdu limitá pa 15 minüt, e kapasidat di delivery por usa un periodo mas largu (por ehèmpel 3 delivery pa 30 minüt). Di algun manera e mekanismo mester por trata ku e diferensia aki den granularidat di periodo. ### Pidi di antemano E posibilidat ku hende por pone nan orden di antemano ta agregá na e reto. Hende por skohe un time slot den futuro i tin e kapasidat nesesario reservá. Algun biaha mi ta mira hende pone nan orden dianan di antemano pa asegurá ku nan haña nan kuminda entregá riba un dia i ora spesífiko. Esaki ta nifiká ku tin (por lo menos) dos tempu asosiá ku kada orden: ora di orden i ora di entrega. ### Reservá i libera kapasidat Mayoria di dònonan di negoshi ta rekerí pago online pa ordenan online; esaki ta pa asegurá ku tur orden ta legítimo i ningun kapasidat (òf kuminda) ta wòrdu gastá riba no-show òf orden fantasma. E problema ku pagonan_online (https://willem.com/en/2020-03-25_designing-and-implementing-a-micro-payment-system/) ta ku no tur transakshon ta eksitoso. Algun biaha un pago ku kredito òf débito ta wòrdu refusá (por ehèmpel pa fondo insufisiente). Algun biaha hende djis sera e app promé ku kompletá e orden. E sistema mester reservá e kapasidat nesesario pa un orden dá miéntras e ta pèrmití hende hasi e pago online, i e mester libera e kapasidat reservá si e orden ta wòrdu abandoná òf si e pago faya. ### Volumen haltu, velosidat haltu Ultimo ma no menos importante, e mekanismo mester ta konfiabel i di bon rendimentu. Disponibilidat di orden mester wòrdu determiná den milisegundonan mes miéntras e ta trata ku konkurensia pisá, pasobra tin hopi kliente diferente konektá ku e app di kuminda durante ora di rush. Ora un hende pone un orden, e ta afektá e disponibilidat pa tur otro orden (potensial). No tur hende lo ta konektá di manera konfiabel, pasobra algun hende ta usa e app riba telefòn ku resepshon malu òf wifi. E sistema mester funshoná bon bou di kondishon variá ku hopi hende diferente konektá. ## Lambda Architecture E Lambda_Architecture (https://en.wikipedia.org/wiki/Lambda_architecture) ta un manera pa trata ku kantidat grandi di dato dor di usa tantu stream processing komo batch processing. Un lambda architecture ta depende di un model di dato ku un fuente di dato append-only i inmutabel, ku ta konsistí di evento ku timestamp. ### Dato inmutabel Esaki ta un fundamentu masha importante pa e mekanismo: tur dato ta tin timestamp i *nunka* ta kambia. Na lugá di kambia rekòrdnan existente, rekòrdnan nobo ta wòrdu agregá djis pa sobreskirbi e rekòrdnan existente. Esaki ta pèrmití konkurensia haltu i algoritmonan distribuí, pasobra sinkronisashon ta bira mas simpel: bo so tin ku buska dato nobo (na lugá di tantu nobo komo aktualisá!). ### Realtime / speed layer E stream processing, òf realtime/speed layer, den un lambda architecture ta desèñá pa duna repuesta super lihé na nesesidat di dato na tempu real. E ta mantené view i métrika basá riba prosesamentu di evento na tempu real. ### Precomputation layer E batch processing, òf precomputation layer, ta duna un base kompletu i eksakto di tur dato den e sistema. Komo prosesá kantidat grandi di dato por tuma tempu, e batch processing no ta lihé sufisiente pa hasi tur kos mesora. Esaki ta pakiko e dos layer ta traha huntu den un lambda architecture. ## Implementashon E servernan di backend ku ta maneha orden di kuminda for di e app ta traha ku un stream di dato di evento ku timestamp. Na esensia: kada orden ta un evento den e sistema. Kada orden ta wòrdu warda ku su dia/ora di orden, dia/ora di despachu (ora programá di delivery òf pickup), detaye di kliente i kontenido di orden (kantidat di plato, etc). ### Reservá i libera kapasidat Si pago ta faya òf si un orden ta wòrdu abandoná, un orden "negativo" ta wòrdu agregá na e stream di dato. E ta neutralisá kualkier efekto riba e restrikshonnan di kapasidat ku su métrikanan negativo. Por ehèmpel: pa kansela un orden di tres pizza, un orden negativo di "minus tres pizza" ta wòrdu krea den e stream di dato ku e mes timestamp di despachu. Esaki ta un manera elegante pa asegurá ku kapasidat ta wòrdu reservá i liberá. ### Métrika multidimensional na tempu real Na lugá di abstrakshon kapasidat den kontadornan, e server di backend ta usa e dato *real* di e stream pa kontestá konsulta pa métrika na tempu real. Esaki ta pèrmití e sistema trata ku diferensia den granularidat di periodo. ![Un stream di evento di orden ta e kurason di e mekanismo, konsulta ta wòrdu kumplí dor di wak e stream aki: kuantu pizza lo ta prontu na 18:00hrs?](https://willem.com/global/images/1e59e0b31de7.webp) E promé biaha ku un konsulta pa un métrika dá ta wòrdu risibí, e sistema ta karga dato históriko via un mekanismo di batch pa inisialisá e model ku e por mantené aktualisá na tempu real. E métrika aki ta wòrdu mantené aktualisá dor di wak tur orden nobo ku ta drenta e sistema miéntras konsulta pa un métrika dá ta sigui yega. Ora e dato no ta wòrdu pidí mas, e model ta wòrdu kitá for di memoria. Si e ta nesesario di nobo, e proseso ta repití. E kos grandi di e aproximashon aki ta ku mayoria di konsulta ta wòrdu kontestá den milisegundonan mes, pasobra nan ta wòrdu lesa direkt for di RAM sin interakshon ku database òf disko. Esaki ta pèrmití rendimentu ultra haltu riba un base di "need to have". Esaki ta traha bon ku e app di kuminda pasobra no *tur* periodo ta mes popular. E app di kuminda ta konsultá biaha tras biaha un server sentral di kapasidat ku ta mantené e métrika di fila. E ora ei e ta filtrá e time slot disponibel dor di wak kiko un persona ta skohe awor pa su orden. Skohe un time slot (probabel) disponibel p'esei ta pasa riba banda di kliente, ku ta redusí e karga riba e backend. Ora un orden ta wòrdu pone, e backend ta reservá e kapasidat dor di aktualisá e métrika sentral di fila, blòkea otro hende pa no reklamá e mes lugá den fila. ## Konklushon Mekanismonan di fila por ta reto ora bo trata ku varios métrika ku ta kontrolá e velosidat. Bo mester di bèrdat tuma tempu pa modelá esaki bon, pensa riba e tipo di dato ku bo *di bèrdat* tin mester pa hasi chèk relashoná ku fila. Awor bo sa ku pidi tres pizza no ta asina simpel! Garantisá ku nan por wòrdu sirbi kayente i na tempu ta un gran reto téknico, apart di ta un bon kushinero. Kontentu pa bo ku *mi* no ta fokus riba esei último, ha!