AN EXTRAORDINARY SMALL ONLINE STORE Why settle for more? A store has a backend and frontend. The backend takes care of inventory management and the frontend the display. S 1. THE BACKEND The backend of a store really only needs to keep track of what it sells. Transaction history, customer profiles, discounts, shipping, etc are all secondary in this. A product or service has: * An identifier * Stock * Price An identifier is a bit of information which identifies a product or service. Since we are aiming for the smallest store possible we simply increment an identifier number to keep it as small as possible. If proper names are required, they themselves can be used as the identifier, or a mapping can be updated and sent out to clients. Identifiers must never change. The stock is similar as well, and can use variable-width integers too. To really reduce this down, we can ignore counting, and just say if it's in-stock or out-of-stock. The price is the most complicated component. There's the currency, integer and fraction parts. Luckily we know the fraction part will always be less than 100. The currency can use the same identifier type as discussed earlier. Clients will need to be notified what identifier maps to what real world currency. The integer part can be arbitrarily large, so we must again track the largest number. We can reduce the complexity of the price though if we deal in our own currency, or "token", like how you trade in tickets for a prize. This lets our system ignore other complications like taxes. Then we create a list of items which cost a certain amount of tokens. Let's examine the following table: Identifier: 1 Stock: In stock Price: 10 tokens Identifier: 2 Stock: In stock Price: 199 tokens Identifier: 3 Stock: Out of stock Price: 1 token This would mean the total bits required to store this "store" is: 4 bits per identifier 1 bit per stock 4 bits per price --------------------- 9 bits total per product/service 4 bits per identifier gives 3 bits of numbers (0-7), meaning up to 8 products. 1 bits per stock means it's out-of-stock (0) or in-stock (1). 4 bits per price represents 1 bit for extensions and 3 bits for doubling. This means prices could be like: 0, 1, 2, 4, 8, etc. Since 3 bits goes up to 7, that means 128 is the max price unless we extend. This gives some nice granularity. In a traditional database this would probably be more like: 64 bits per identifier 32 bits per stock 32 + 32 bits per price ---------------------- 160 bits per product/service Which is ~13x the size of the original. We ignore the transport protocol in both circumstances, considering they are both free to use the most efficient solution. S 2. THE FRONTEND The display of a store is little heavier than the backend. It must present the information in an understandable (and sometimes appealing) manner. Each product or service needs a description of itself. There are too many possibilities here, so plain text is really the only sane option.