4 ms·

Any self respecting e-commerce site would want fault tolerance and strong consistency even with potential network partitions, so definitely not SQLite as descri

Any self respecting e-commerce site would want fault tolerance and strong consistency even with potential network partitions, so definitely not SQLite as described in article

sodapopcan 3y ago
They aren't necessarily going to have all this. Lots of smaller ecom shops can run on a single server per region. If you're a North American company selling a few hundred t-shirts per day in NA and EU, it could probably be fine, no? I'll admit I'm not speaking from experience. Rather, I have experience in everything I just said only I was using pg, not sqlite. But I've been very interested in sqlite recently.
- emodendroket 3y ago
  Why even build your own e-commerce Web site at all in that case? It’s undifferentiated work.
  - evantbyrne 3y ago
    As with anything, the typical business can use something off-the-shelf, but a certain percentage are doing things differently enough that custom development becomes practical. I had to custom build the billing system for Beaker Studio to properly meter customers. Even Stripe's metering API wasn't flexible enough to handle per-hour metering.
    - emodendroket 3y ago
      I find it hard to imagine a reason a shop selling 100 tee shirts in a day would need any custom functionality since this is basically the exact use case all these OOB e-commerce tools are built for.
      - evantbyrne 3y ago
        Yeah, you're probably right about that. Main thing that would likely be custom would be the design.
      - sodapopcan 3y ago
        I've worked for such a place. Off-the-shelf solutions are trying to be everything to everyone and you can end up customizing the crap out of them to the point where it can become more onerous than just building your own. The place I worked was also print-on-demand service and had hundreds of thousands of SKUs as well as allowed customers to make custom products and we also hosted some peoples' shops. Shoehorning that into a custom solution was painful. I work at a very similar place now that uses Shopify. Managing that many SKUs on Shopify is crazy painful. The thing is is that custom ecom solutions really aren't that hard. The off-the-shelf ones are complex because, as stated above, they are trying to be everything to everybody.
      - sarchertech 3y ago
        One of the first commercial projects I worked on nearly 20 years ago was a tshirt shop. And the precious company I worked for was a comparatively huge logistics startup. I’m fairly confident I could spend a month or so writing a custom solution for a shop selling and shipping a few hundred tshirts a day that would save them enough money to break even on the software in a few years (compared to off the shelf solutions). If I was starting my own tshirt company, I’d definitely do it.
      - MyneOutside 3y ago
        In our B2B space there are tons of custom business rules. For example, you place orders per manufacturer and each manufacturer has its own minimum and reorder amounts and reqs on an order, promotions, business rules, etc. This is for business that have been around 25-30 years. We did an evaluation on several out of the box ecommerce solutions and none of them were able to meet the requirements that absolutely had to be there. Shopify flat out said no, they can't help us, etc.
    - parineum 3y ago
      > the typical business can use something off-the-shelf I think we generally have this problem. It's not the typical business that can use that stuff, it's the average business. Unfortunately no business is the average business.
  - bcrosby95 3y ago
    I don't know about nowadays. 8 years ago we built our own ecommerce site + warehouse app (inventory tracking, fulfillment, receiving) for a few hundred orders per day. The goal was to be able to better see profit margins by product, track where the money was going/coming from in detail, along with cleaning up the inventory management part of the operation. The warehouse people loved the change because it really streamlined the fulfillment process and it basically reduced their errors to zero. Owners loved it because of the all the cost/price tracking. It took about 6 months of work by 2 devs. Before this they were on woocommerce. It was slow as shit. We looked at shopify but the integrations with 3rd party warehouse stuff was bad. The other solutions we looked at were overly complicated swiss army knives.
    - sodapopcan 3y ago
      This is very close to my experience as well. Unfortunately, it was in reverse for me :( We had a custom solution and people were happy. A new tech lead came in and didn't like that the custom solution was PHP that still had some legacy spaghetti in it, so we switched to an off the shelf solution. It was very painful. People were unhappy.
      - pmarreck 3y ago
        > that still had some legacy spaghetti in it I'm going to take a wild ass guess here that you are wildly understating the "bit of legacy spaghetti"
        sodapopcan 3y ago
        Your wild guess is flat out wrong. When the previous tech lead came in the entire thing was spaghetti. His strategy was to slowly start bringing in some order to the chaos which we did, diligently, over two years making tons of progress. It was a homebrewed framework but it was really nice (he'd had years of experience contributing to Drupal). All the business critical functionality had been converted to this. The spaghetti parts were features that were essentially "complete". Since they never needed updating, they worked fine as they were.
- endisneigh 3y ago
  It’s not about the size. Issues result in lost sales which means lost revenue. You would want fault tolerance regardless of how big you are.
  - deleted 3y ago
    [deleted]
  - deleted 3y ago
    [deleted]
  - bootsmann 3y ago
    There is a cost to fault tolerance as well, if you lose $100 per month due to fault tolerance thats worth about 30 developer minutes. Do you really get good fault tolerance for 30m of monthly work?
    - erulabs 3y ago
      You do with RDS and/or other hosted database services, hence their popularity.
  - sodapopcan 3y ago
    That's something for me to look into. Like what would it would look like in each? I've never been the dba-type in past jobs. I'm relatively well-versed in SQL but not administration.
pmarreck 3y ago
https://rqlite.io/ https://rqlite.io/ at least looks like an interesting option, here
geysersam 3y ago
Why would they need strong consistency? What's shown on the page the user sees is never strongly consistent with the db anyway.
- unshavedyak 3y ago
  I have this same discussion at work frequently. Everything thinks they need instantly up to date, yet our customers work for 10 minutes on a stale document and no one cares.

Any self respecting e-commerce site would want fault tolerance and strong consistency even with potential network partitions, so definitely not SQLite as described in article

sodapopcan 3y ago

They aren't necessarily going to have all this. Lots of smaller ecom shops can run on a single server per region. If you're a North American company selling a few hundred t-shirts per day in NA and EU, it could probably be fine, no? I'll admit I'm not speaking from experience. Rather, I have experience in everything I just said only I was using pg, not sqlite. But I've been very interested in sqlite recently.

emodendroket 3y ago
Why even build your own e-commerce Web site at all in that case? It’s undifferentiated work.
- evantbyrne 3y ago
  As with anything, the typical business can use something off-the-shelf, but a certain percentage are doing things differently enough that custom development becomes practical. I had to custom build the billing system for Beaker Studio to properly meter customers. Even Stripe's metering API wasn't flexible enough to handle per-hour metering.
  - emodendroket 3y ago
    I find it hard to imagine a reason a shop selling 100 tee shirts in a day would need any custom functionality since this is basically the exact use case all these OOB e-commerce tools are built for.
    - evantbyrne 3y ago
      Yeah, you're probably right about that. Main thing that would likely be custom would be the design.
    - sodapopcan 3y ago
      I've worked for such a place. Off-the-shelf solutions are trying to be everything to everyone and you can end up customizing the crap out of them to the point where it can become more onerous than just building your own. The place I worked was also print-on-demand service and had hundreds of thousands of SKUs as well as allowed customers to make custom products and we also hosted some peoples' shops. Shoehorning that into a custom solution was painful. I work at a very similar place now that uses Shopify. Managing that many SKUs on Shopify is crazy painful. The thing is is that custom ecom solutions really aren't that hard. The off-the-shelf ones are complex because, as stated above, they are trying to be everything to everybody.
    - sarchertech 3y ago
      One of the first commercial projects I worked on nearly 20 years ago was a tshirt shop. And the precious company I worked for was a comparatively huge logistics startup. I’m fairly confident I could spend a month or so writing a custom solution for a shop selling and shipping a few hundred tshirts a day that would save them enough money to break even on the software in a few years (compared to off the shelf solutions). If I was starting my own tshirt company, I’d definitely do it.
    - MyneOutside 3y ago
      In our B2B space there are tons of custom business rules. For example, you place orders per manufacturer and each manufacturer has its own minimum and reorder amounts and reqs on an order, promotions, business rules, etc. This is for business that have been around 25-30 years. We did an evaluation on several out of the box ecommerce solutions and none of them were able to meet the requirements that absolutely had to be there. Shopify flat out said no, they can't help us, etc.
  - parineum 3y ago
    > the typical business can use something off-the-shelf I think we generally have this problem. It's not the typical business that can use that stuff, it's the average business. Unfortunately no business is the average business.
- bcrosby95 3y ago
  I don't know about nowadays. 8 years ago we built our own ecommerce site + warehouse app (inventory tracking, fulfillment, receiving) for a few hundred orders per day. The goal was to be able to better see profit margins by product, track where the money was going/coming from in detail, along with cleaning up the inventory management part of the operation. The warehouse people loved the change because it really streamlined the fulfillment process and it basically reduced their errors to zero. Owners loved it because of the all the cost/price tracking. It took about 6 months of work by 2 devs. Before this they were on woocommerce. It was slow as shit. We looked at shopify but the integrations with 3rd party warehouse stuff was bad. The other solutions we looked at were overly complicated swiss army knives.
  - sodapopcan 3y ago
    This is very close to my experience as well. Unfortunately, it was in reverse for me :( We had a custom solution and people were happy. A new tech lead came in and didn't like that the custom solution was PHP that still had some legacy spaghetti in it, so we switched to an off the shelf solution. It was very painful. People were unhappy.
    - pmarreck 3y ago
      > that still had some legacy spaghetti in it I'm going to take a wild ass guess here that you are wildly understating the "bit of legacy spaghetti"
      - sodapopcan 3y ago
        Your wild guess is flat out wrong. When the previous tech lead came in the entire thing was spaghetti. His strategy was to slowly start bringing in some order to the chaos which we did, diligently, over two years making tons of progress. It was a homebrewed framework but it was really nice (he'd had years of experience contributing to Drupal). All the business critical functionality had been converted to this. The spaghetti parts were features that were essentially "complete". Since they never needed updating, they worked fine as they were.
endisneigh 3y ago
It’s not about the size. Issues result in lost sales which means lost revenue. You would want fault tolerance regardless of how big you are.
- deleted 3y ago
  [deleted]
- deleted 3y ago
  [deleted]
- bootsmann 3y ago
  There is a cost to fault tolerance as well, if you lose $100 per month due to fault tolerance thats worth about 30 developer minutes. Do you really get good fault tolerance for 30m of monthly work?
  - erulabs 3y ago
    You do with RDS and/or other hosted database services, hence their popularity.
- sodapopcan 3y ago
  That's something for me to look into. Like what would it would look like in each? I've never been the dba-type in past jobs. I'm relatively well-versed in SQL but not administration.

pmarreck 3y ago

https://rqlite.io/ https://rqlite.io/ at least looks like an interesting option, here

geysersam 3y ago

Why would they need strong consistency? What's shown on the page the user sees is never strongly consistent with the db anyway.

unshavedyak 3y ago
I have this same discussion at work frequently. Everything thinks they need instantly up to date, yet our customers work for 10 minutes on a stale document and no one cares.