So , you ' d wind up with a type called urlDB or whatever , which would encapsulate the sql . DB object . Then you define a HandleHTTP method on urlDB so that it satisfies the interface . Then in your main function you create the urlDB object and simply call , urlDB . That way , all your handler functions will have access to the database without the need for a global var . As for NewEncoder In Go , it ' s very common to use the io . Reader and io . Writer interfaces to stream data around instead of reading it all into memory . If you were encoding a large struct , for example , NewEncoder could drastically reduce the peak memory consumption of your app . But honestly , the performance aspect is incidental . The real lesson is to get in the Go mindset of wiring up interfaces . Insider your handler function , you want to write data out via the . One way to look at it is ok , w , has a method called Write that takes a byte . So I need to pack my data into a byte somehow , and then call Write on it . But the more idiomatic approach is ok , w is an io . Writer . What tools do I have that play well with the io . Writer interface ? Ah , I see that I can write my data to an io . Writer directly by using NewEncoder . The more you familiarize yourself with the standard library , the more natural this mindset will feel . The mapstring thing isn ' t super important , but it ' s good practice if there ' s any chance you ' ll use the type elsewhere . It also improves readability , since you ' ll have an expression like URLResponseurl , err instead of a generic map . Finally , if someone wanted to write a Go package that used your API , they could import your package and decode directly into your URLResponse type instead of reimplementing the logic themselves . I guess my main critique of Tiny is that it ' s methods are kind of backwards . That is to say when you call t . save , t is being implicitly saved to a global db object . This behavior is a little surprising , since a Tiny object is just a collection of inert data . I would expect the args to be reversed , i . e . db . savet . Furthermore , a method called save should only be concerned with moving data from memory to disk . Generatingencoding the short URL should be handled in a separate function . This will make the coder easier to follow , make it easier to test , etc . As for hashing , you can truncate the hash as necessary . For example , 6 bytes of a hash will give you 280 trillion possible short URLs . As with any shortening service , it is desirable to use as few bytes as possible , but you need to weigh that against your other concerns .