
Link Deployment with AWS LambdaEdge - jessedhillon
https://blog.plaid.com/link-deployment-with-aws-lambda-edge/
======
LusoTycoon
Why the viewer request latency? 50ms kind of defeats its purpose

~~~
jalk
I believe that lambda CPU goes hand in hand with memory. Your lambda@edge
function will only deploy with 128mb of ram allocated and hence get very
little CPU. 50ms is not low-latency in my book either. See
[https://serverless.zone/my-accidental-3-5x-speed-increase-
of...](https://serverless.zone/my-accidental-3-5x-speed-increase-of-aws-
lambda-functions-6d95351197f3)

------
wcdolphin
“As an alternative to cookies, then, we opted to hash the user’s IP address
and their User-Agent string”.

So if a user is on a mobile device and switches networks, 50/50 they will
receive a consistent version?

Did you consider using Geo based filtering? Iirc Cloudfront has support for
geo restrictions, so you could create multiple distributions and restrict one
to a geo for rollout.

~~~
jdudek
Yes, switching networks can indeed cause users to receive different versions
within the 3 hour window. In general we ship small, incremental changes that
rarely even are visible to the user, so a small likelihood of serving
inconsistent version is acceptable.

Interesting idea with geo restrictions. Does this allow more granularity than
country-level filtering? Most of our audience is based in the US, so country-
level setting does not give us enough flexibility.

There is also value in knowing the percentage of users receiving the new
version. It’s just more predictable and easier to analyze the data if the
ratio of new-to-old is known beforehand.

