Prueba técnica - SSE

#6 eso se lo come el worker replicando el repo externo dentro de la infra propia y haciendo push async del diff. No me acabó gustando mucho la idea, me pareció algo ñapas pero la verdad que lo poco que me decían era a cuentagotas.

#7 Cada uno funciona distinto supongo. Yo lo que más noto para aprender es simplemente ir curioseando leyendo a gente hablar en inet o leer artículos y cosas que me voy encontrando. Si algo de lo que leo no me suena me meto en un rabbit hole. Habrá días que hago una lectura muy superficial y otros más a fondo pero en el agregado a lo largo de los años creo que he ido aprendiendo bastante así. De libros ahora estoy con designing data intensive applications y creo que es de los pocos que recomendaría de forma sincera.

Algo útil es seguir a gente buena en redes sociales que hable de su curro. Normalmente huyo de los gurús del XP porque parecen una secta y están en bucle repitiendo lo mismo.

Tal como yo lo veo, tu problema es que tienes dos fuentes de la verdad: el fichero y la memoria de tu servicio. En un único servicio pues tira que te vas, pero si empiezas a replicarlo hasta N servicios tendrás N+1 fuentes de verdad que empezarán a divergir malamente (en cuanto se levante n2 vas a perder lo que tengas en memoria en n1 y tendrás falsos positivos). Sí o sí, necesitas reducirlo a una sola y que no implique roundtrips de red, si no he entendido mal. Es decir, que debería estar en memoria.

Lo único que se me ocurre es tener un servicio como fuente de verdad. El worker alimenta la memoria de ese servicio (fuente) y el resto de servicios (checkers) le hacen llamadas para comprobar IPs. De esa manera ya puedes escalar todos los checkers que quieras sin comprometer la integridad de los datos. Si el servicio fuente tuviese que escalar, dado que el intervalo de refresco es de un minuto deberías poder levantar hasta un Windows entero si hiciera falta entre pool y pool para que la memoria de tus servicios no tengan discrepancias. Entendiendo que parte del levantado del servicio fuente es meter la lista en memoria, claro.

Todo esto suponiendo que añadir una llamada HTTP más no es problema. Esto es, no se considera roundtrip, no pasa nada que sea bloqueante, etc.

#11 Eso es lo deseable, pero a mí me tiraron una vez por, y cito, "no ceñirme a la descripción del problema y querer buscar atajos". Lo único que hice fue preguntar por qué unas constraints del problema eran como eran y cuál era el motivo XD

Este hilo es genial para darme cuenta de que no tengo ni zorra XD

Claro, con sharding basicamente se divide el problema en N, y algo tan sencillo como los 4 primeros bits de la IP baja muchisimo la cantidad de datos que se han de almacenar. Pero eso lleva al problema de como cargar los datos de una manera efectiva y que hacer cuando se desbalancea los datos. Para cargarlos de manera efectiva supongo que deberia de haber algo que divida los datos primero y los deje listos para los shards, cosa que veo trivial.

Lo que no se de normal es lo bien que se ve poner un redis/dynamodb como backend de algo y quedarse tan pancho en una entrevista que se supone que evaluan el conocimiento. Nano si hasta el mas palurdo te mete una mierda del estilo distribuida sin pensar y ale, tienes tu escalado horizontal de free sin tener que poseer mas de 3 neuronas. No se si es lo que buscaban pero vamos xddd

#21 si pensar en "security groups" es una buena manera de avanzar porque seguro que hay doc o blogs de los proveedores cloud tipicos... googleo y al primer resultado ya tengo la respuesta al ejercicio:

https://www.reddit.com/r/aws/comments/sozupa/security_groups_under_the_hood/

AWS para estas cosas sobre ec2 tiene sus chips dedicados (los nitro? o algo asi, no domino de aws). Y google/microsoft, uno de los dos, ha comprado este año una startup de chips para hacer lo mismo.

Seguro que si googleas docu de CISCO e IBM encontraras mucha docu de como montar estas cosas a varios niveles y los trade offs. hardware switches/routers => hardware network => hyper visors => kernel => user

para los requerimentos de monitorear, no se que info se queda al descarte, pero puedes enrutar a un sandbox y hacer lo que quieras ahi.

al final, la solucion mas sencilla y simple, siempre es la mejor.

#23 Creo que te lias con el enunciado. Si quiero filtrar IPs como pide la descripcion del problema sera en todo el sistema. Que sentido tiene solo el path interno de autorizar? XY problem, huevo o gallina. El problema es filtrar IPs / spam y que sea rapido. No bloquear ips random en /auth. O es que habra casos que /auth hay que bloquear pero otros no? Fijate que si ese fuese el problema me lo explicarias de otra manera...

Ahora, como nota, si de verdad el enunciado es ese. Y me piden hacer un servicio HTTP. Mi respuesta es que no quiero trabajar en esa empresa. Porque no tiene sentido lo que piden. Demuestran no tener ni idea. O demuestran no tener las capacidades tecnicas para implementar la solucion buena.

Y para terminar, la solucion propuesta no es hacer WAF o security groups... Al menos la mia. Como he dicho arriba la solucion propuesta es "aplicar el bloqueo" en la primera capa posible. Sin complicarme mucho sigo pudiendo hacer todo esto en el kernel de mis instancias sin necesidad de tener un servicio http. Ejemplos malos:

• No tiene ningun sentido tener un servicio para esto. Es como tener un loadbalancer o un reverse proxy que consulta a otro servidor por HTTP donde tiene que balancear... No el loadbalancer ya tiene las rutas en el binario... Y si puedes mover al kernel el trabajo mejor.

• O para los FPeros, tengo un CRUD que consulta a otro servicio HTTP para saber a que DB tiene que escribir. Son niveles de indireccion inecesarios. Si tengo un CRUD para guardar vehiculos en mi db de vehiculos, no voy a crear un servicio para devolverle al servicio CRUD de vehiculos donde tiene que guardar los vehiculos ...

El ultimo ejemplo suena absurdo verdad? Asi de absurdo es el enunciado si de verdad me pide eso. Y estas cosas por desgracia las he visto muchas veces, las leo en blog posts y hasta hay gente que te vende libros con boberias asi. Asi que no me pareceria raro que fuese lo que de verdad te piden.

Estoy ruteando trafico de IPs por varios niveles, pero al llegar al final de todo, quiero implementar un servicio que lo bloquee... Despues de dar 10 saltos en mi sistema. Y para hacer este bloqueo, voy a crear un servicio HTTP extra para dar otros 4 saltos. Si de verdad esto no te parece absurdo... vamonos. La gente que no tiene ni puta idea se hace la picha un lio por dos chorradas y te hace un sistema distribuido que no tiene sentido porque potato.

A ver, hay que tener en cuenta que es un ejercicio donde quieren normalmente ver cómo implementas algo, y que cosas tienes en cuenta para hacerlo en un servicio http. La lógica de dentro la suelen poner que tenga algo de miga implementar, royo esto o un rate limit o lo que sea y que no te dejen usar lo que ya está hecho y más que estudiado.

A no ser que el puesto sea más de infra y te pidan buscar soluciones para el problema real de filtrar allow_list /deny_list por CIDRs, en cuyo caso el enunciado sería algo diferente.

#29 pues yo leo #1 y de developer 0 pelotero.