I built a tool to generate a PDF for each row of a Google sheet. For example, you can generate 100 personalized PDFs (like certificates) for 100 students listed in a Google Sheet.

https://sheetstopdf.com/

Once you sign up and connect your Google sheet, it generates a template (using AI) based on your data, which you can edit in a Notion-like editor. You can then generate PDFs for your entire sheet or a for a range of rows.

Some use cases I'm seeing:

* Certificates for students or course completions

* Monthly invoices for all your clients (https://sheetstopdf.com/use-cases/business/invoices)

* Personalized reports with individual client data

* Event tickets or conference badges

* Contracts, offer letters, or any personalized documents

* Really anything where you have rows of data that need to become individual PDFs

Would love to hear what you think or if you have use cases I haven't thought of yet!

A modern day mail merge.

https://en.wikipedia.org/wiki/Mail_merge

I'm building an app to help users find free and paid street parking in Vancouver: https://instaparkr.com/

While apps like Parkopedia and SpotAngels tackle the same problem, their one-size-fits-all approach often results in incomplete, missing, or outdated data. My approach is different: go deep on one city at a time by combining multiple publicly available datasets. This doesn't scale horizontally since each city has different data sources and formats, but the goal is to become the definitive parking resource for one city, build automation to keep it current, then methodically expand city by city.

If you are based in Vancouver, do give it a go. Your feedback would be awesome!

I think the key concept here is atomicity. If some API is responsible for creating a job, storing it in the database AND publishing it can never be an atomic operation. Both the database and pub/sub servers are separate network connections from the application server. For example, if you save the record first and then publish, It's quite possibe that you save the record in the database and then lose the connection to the pub/sub server when publishing. If this happens, you can never know if the pub/sub server received the request and published it. In systems where it's critical to guarantee that a record was saved and guarantee that it was published as well, the only way to do that is by using a single external connection - in this case to a Postgres DB. We've used the same setup on an AWS RDS t2.medium machine to process over 600 records/second.

>If some API is responsible for creating a job, storing it in the database AND publishing it can never be an atomic operation.

We use transactional outbox for that - we insert a record about the event into the event table in the same transaction as the rest of the operation (providing atomicity), and then a special goroutine reads this table and pushes new events to the message broker on a different server. In our design, there are multiple services which might want to subscribe to the event, and the rule is that they shouldn't share their DB's (for proper scaling) so we can't handle event dispatch in some single central app instance. Of course we could implement our own pub/sub server in Go over a DB like Postgres if we wanted, but what's the point of reinventing the wheel if there's already existing battle-tested tools for that, considering you have to reimplement: queues, exchanges, topics, delivery guarantee, proper error handling, monitoring etc.

Distributed transactions are hard. And if queue data is the source of truth for something then they must be durable. All that said, when traffic volume, payload size, or throughout demands something specialized then it makes sense to do it.

If I'm building one shed then maybe I only need 5 tools, while a shed factory might use 100. Context matters.

You can use transactional outbox pattern to solve this.