Hi everyone, in an effort to understand GenServers and Registry, I put together a small URL shortener service, without a database. Each “link” is registered using Registry, with the shortcode as a key to find the process. I am aware that this probably would not be a suitable approach for a production system, but it was fun to mess around with GenServer and Registry.
I would love some feedback on it:
what is good
what is bad
if my tests are relevant
This actually made me think about how your architecture changes when you bring in OTP patterns in your app design from the start, especially with persistence strategies. If you can store state inside a process, then how do you decide when to persist? What data to persist? I can definitely see a CQRS/ES type of architecture, with the event stores inside a DB, and having the read models in-memory as processes. Would this be a valid approach?
In my experience, people’s instinctual response to Memory Images (keeping the application’s entire working state in memory) is vehement rejection, but in reality I’ve found it to be a really elegant solution to a lot of hard problems.
It opens up worlds of flexibility for managing read models (that can be reshaped, regenerated, and refactored on the fly), and makes conflict resolution fairly simple when compared to other solutions that rely on complicated consensus algorithms between distributed nodes.
One quick thing I noticed in your project is that there might be a race condition when generating new short codes for links. What would happen if two people simultaneously try to generate a new shortened link, and generate_shortcode returns the same shortcode for each? The first caller to reach Link.start_link would succeed, but the second call to Link.start_link would fail because the name is taken, right?
Instead of doing your Registry.lookup in generate_shortcode to detect used codes, you might want to listen for :already_started failures from Link.start_link instead.
That being said, the problem I described is very unlikely to happen in the real world. Just something to think about. Distributed systems are hard.
